Exchanging data associated with a communication session within a communications system

ABSTRACT

In an embodiment, objects are downloaded to an access terminal (AT) based on which window(s) are prominently displayed on the AT. In another embodiment, objects are downloaded to the AT based on a set of user-specified object download priorities. In another embodiment, a portion of a streaming data session to the AT is de-prioritized in response to a transition of a display of the AT from a first set of windows associated with the streaming data session to a second set of windows associated with a different session. For example, the de-prioritization can result in the portion (e.g., a video-portion of a audio and video conference) being omitted or reduced. In another embodiment, in response to the AT entering a limited environment, objects being downloaded to the AT can be dynamically altered to conform with the AT&#39;s limited environment.

CLAIM OF PRIORITY

The present application for patent is a Divisional of Non-Provisionalapplication Ser. No. 13/096,700, entitled “EXCHANGING DATA ASSOCIATEDWITH A COMMUNICATION SESSION WITHIN A COMMUNICATIONS SYSTEM”, filed onApr. 28, 2011, which in turn claims priority to Provisional ApplicationNo. 61/330,179, entitled “EXCHANGING DATA ASSOCIATED WITH ACOMMUNICATION SESSION WITHIN A COMMUNICATIONS SYSTEM”, filed Apr. 30,2010, each of which is assigned to the assignee hereof and herebyexpressly incorporated by reference herein in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention are directed to exchanging dataassociated with a communication session with a communications system.

2. Description of the Related Art

Wireless communication systems have developed through variousgenerations, including a first-generation analog wireless phone service(1G), a second-generation (2G) digital wireless phone service (includinginterim 2.5G and 2.75G networks) and a third-generation (3G) high speeddata/Internet-capable wireless service. There are presently manydifferent types of wireless communication systems in use, includingCellular and Personal Communications Service (PCS) systems. Examples ofknown cellular systems include the cellular Analog Advanced Mobile PhoneSystem (AMPS), and digital cellular systems based on Code DivisionMultiple Access (CDMA), Frequency Division Multiple Access (FDMA), TimeDivision Multiple Access (TDMA), the Global System for Mobile access(GSM) variation of TDMA, and newer hybrid digital communication systemsusing both TDMA and CDMA technologies.

The method for providing CDMA mobile communications was standardized inthe United States by the Telecommunications IndustryAssociation/Electronic Industries Association in TIA/EIA/IS-95-Aentitled “Mobile Station-Base Station Compatibility Standard forDual-Mode Wideband Spread Spectrum Cellular System,” referred to hereinas IS-95. Combined AMPS & CDMA systems are described in TIA/EIA StandardIS-98. Other communications systems are described in the IMT-2000/UM, orInternational Mobile Telecommunications System 2000/Universal MobileTelecommunications System, standards covering what are referred to aswideband CDMA (WCDMA), CDMA2000 (such as CDMA2000 1xEV-DO standards, forexample) or TD-SCDMA.

In wireless communication systems, mobile stations, handsets, or accessterminals (AT) receive signals from fixed position base stations (alsoreferred to as cell sites or cells) that support communication links orservice within particular geographic regions adjacent to or surroundingthe base stations. Base stations provide entry points to an accessnetwork (AN)/radio access network (RAN), which is generally a packetdata network using standard Internet Engineering Task Force (IETF) basedprotocols that support methods for differentiating traffic based onQuality of Service (QoS) requirements. Therefore, the base stationsgenerally interact with ATs through an over the air interface and withthe AN through Internet Protocol (IP) network data packets.

In wireless telecommunication systems, Push-to-talk (PTT) capabilitiesare becoming popular with service sectors and consumers. PTT can supporta “dispatch” voice service that operates over standard commercialwireless infrastructures, such as CDMA, FDMA, TDMA, GSM, etc. In adispatch model, communication between endpoints (ATs) occurs withinvirtual groups, wherein the voice of one “talker” is transmitted to oneor more “listeners.” A single instance of this type of communication iscommonly referred to as a dispatch call, or simply a PTT call. A PTTcall is an instantiation of a group, which defines the characteristicsof a call. A group in essence is defined by a member list and associatedinformation, such as group name or group identification.

Conventionally, data packets within a wireless communications networkhave been configured to be sent to a single destination or accessterminal. A transmission of data to a single destination is referred toas “unicast”. As mobile communications have increased, the ability totransmit given data concurrently to multiple access terminals has becomemore important. Accordingly, protocols have been adopted to supportconcurrent data transmissions of the same packet or message to multipledestinations or target access terminals. A “broadcast” refers to atransmission of data packets to all destinations or access terminals(e.g., within a given cell, served by a given service provider, etc.),while a “multicast” refers to a transmission of data packets to a givengroup of destinations or access terminals. In an example, the givengroup of destinations or “multicast group” may include more than one andless than all of possible destinations or access terminals (e.g., withina given group, served by a given service provider, etc.). However, it isat least possible in certain situations that the multicast groupcomprises only one access terminal, similar to a unicast, oralternatively that the multicast group comprises all access terminals(e.g., within a cell or sector), similar to a broadcast.

Broadcasts and/or multicasts may be performed within wirelesscommunication systems in a number of ways, such as performing aplurality of sequential unicast operations to accommodate the multicastgroup, allocating a unique broadcast/multicast channel (BCH) forhandling multiple data transmissions at the same time and the like. Aconventional system using a broadcast channel for push-to-talkcommunications is described in United States Patent ApplicationPublication No. 2007/0049314 dated Mar. 1, 2007 and entitled“Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular Network”,the contents of which are incorporated herein by reference in itsentirety. As described in Publication No. 2007/0049314, a broadcastchannel can be used for push-to-talk calls using conventional signalingtechniques. Although the use of a broadcast channel may improvebandwidth requirements over conventional unicast techniques, theconventional signaling of the broadcast channel can still result inadditional overhead and/or delay and may degrade system performance.

The 3^(rd) Generation Partnership Project 2 (“3GPP2”) defines abroadcast-multicast service (BCMCS) specification for supportingmulticast communications in CDMA2000 networks. Accordingly, a version of3GPP2's BCMCS specification, entitled “CDMA2000 High RateBroadcast-Multicast Packet Data Air Interface Specification”, dated Feb.14, 2006, Version 1.0 C.S0054-A, is hereby incorporated by reference inits entirety.

SUMMARY

In an embodiment, objects are downloaded to an access terminal (AT)based on which window(s) are prominently displayed on the AT. In anotherembodiment, objects are downloaded to the AT based on a set ofuser-specified object download priorities. In another embodiment, aportion of a streaming data session to the AT is de-prioritized inresponse to a transition of a display of the AT from a first set ofwindows associated with the streaming data session to a second set ofwindows associated with a different session. For example, thede-prioritization can result in the portion (e.g., a video-portion of aaudio and video conference) being omitted or reduced. In anotherembodiment, in response to the AT entering a limited environment,objects being downloaded to the AT can be dynamically altered to conformwith the AT's limited environment.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of embodiments of the invention and many ofthe attendant advantages thereof will be readily obtained as the samebecomes better understood by reference to the following detaileddescription when considered in connection with the accompanying drawingswhich are presented solely for illustration and not limitation of theinvention, and in which:

FIG. 1 is a diagram of a wireless network architecture that supportsaccess terminals and access networks in accordance with at least oneembodiment of the invention.

FIG. 2A illustrates the carrier network according to an embodiment ofthe present invention.

FIG. 2B illustrates an example of the wireless communication of FIG. 1in more detail.

FIG. 3 is an illustration of an access terminal (AT) in accordance withat least one embodiment of the invention.

FIG. 4A illustrates a conventional manner by which a file can beexchanged between ATs in a communication system.

FIG. 4B illustrates another conventional manner by which a file can beexchanged between ATs in a communication system.

FIGS. 4C and 4D illustrate signaling associated with set-up of afile-transfer session between an originating AT and a target AT inaccordance with an embodiment of the invention.

FIGS. 5A through 5D illustrate different embodiments of interactionsbetween different functional layers of an originating or target accessterminal during a communication session.

FIG. 6A illustrates a conventional mechanism of supporting afile-transfer session concurrently with a streaming or real-timecommunication session.

FIG. 6B illustrates an embodiment of the invention whereby the size ofdata packets for non-streaming sessions, such as file-transfer sessions,are dynamically modified such that delays to packet transmissions ofreal-time or streaming sessions are reduced and/or avoided.

FIG. 6C illustrates another conventional mechanism of supporting afile-transfer session concurrently with a streaming or real-timecommunication session.

FIG. 6D illustrates an embodiment of the invention whereby the size ofdata packets for downlink non-streaming sessions, such as file-transfersessions, are dynamically modified at an application server and/or anaccess network such that delays to packet transmissions of real-time orstreaming sessions are reduced and/or avoided.

FIG. 7A illustrates a conventional mechanism of supporting afile-transfer session concurrently with a streaming or real-timecommunication session.

FIG. 7B illustrates an embodiment of the invention whereby silenceframes for a streaming multimedia session are suppressed and anincreased number of data packets for a low-Quality-of-Service (QoS) ornon-QoS file-transfer session are transmitted.

FIG. 7C illustrates another embodiment of the invention whereby silenceframes for a streaming multimedia session are suppressed and anincreased number of data packets for a low-QoS or non-QoS file-transfersession are transmitted.

FIG. 8A illustrates a process that focuses on the end or completion of aconventional file-transfer session.

FIG. 8B another conventional process focuses on the signaling between atransmitting AT and the application server at the end of a file-transfersession, and as such signaling between a receiving AT and theapplication server is shown via a dotted line.

FIGS. 8C and 8D are each directed to a process related to anopportunistic or preemptive re-transmission of data packets duringperiods where a transmitting AT has a traffic channel (TCH) and is nottransmitting data.

FIG. 8E is directed to another process related to opportunistic orpreemptive re-transmission of data packets during periods where atransmitting AT has a TCH and is not transmitting data in accordancewith an embodiment of the invention.

Each of FIGS. 9A through 9D illustrate a different content-basedcommunicative process associated with a file-transfer session inaccordance with embodiments of the invention.

DETAILED DESCRIPTION

Aspects of the invention are disclosed in the following description andrelated drawings directed to specific embodiments of the invention.Alternate embodiments may be devised without departing from the scope ofthe invention. Additionally, well-known elements of the invention willnot be described in detail or will be omitted so as not to obscure therelevant details of the invention.

The words “exemplary” and/or “example” are used herein to mean “servingas an example, instance, or illustration.” Any embodiment describedherein as “exemplary” and/or “example” is not necessarily to beconstrued as preferred or advantageous over other embodiments. Likewise,the term “embodiments of the invention” does not require that allembodiments of the invention include the discussed feature, advantage ormode of operation.

Further, many embodiments are described in terms of sequences of actionsto be performed by, for example, elements of a computing device. It willbe recognized that various actions described herein can be performed byspecific circuits (e.g., application specific integrated circuits(ASICs)), by program instructions being executed by one or moreprocessors, or by a combination of both. Additionally, these sequence ofactions described herein can be considered to be embodied entirelywithin any form of computer readable storage medium having storedtherein a corresponding set of computer instructions that upon executionwould cause an associated processor to perform the functionalitydescribed herein. Thus, the various aspects of the invention may beembodied in a number of different forms, all of which have beencontemplated to be within the scope of the claimed subject matter. Inaddition, for each of the embodiments described herein, thecorresponding form of any such embodiments may be described herein as,for example, “logic configured to” perform the described action.

A High Data Rate (HDR) subscriber station, referred to herein as anaccess terminal (AT), may be mobile or stationary, and may communicatewith one or more HDR base stations, referred to herein as modem pooltransceivers (MPTs) or base stations (BS). An access terminal transmitsand receives data packets through one or more modem pool transceivers toan HDR base station controller, referred to as a modem pool controller(MPC), base station controller (BSC) and/or packet control function(PCF). Modem pool transceivers and modem pool controllers are parts of anetwork called an access network. An access network transports datapackets between multiple access terminals.

The access network may be further connected to additional networksoutside the access network, such as a corporate intranet or theInternet, and may transport data packets between each access terminaland such outside networks. An access terminal that has established anactive traffic channel connection with one or more modem pooltransceivers is called an active access terminal, and is said to be in atraffic state. An access terminal that is in the process of establishingan active traffic channel connection with one or more modem pooltransceivers is said to be in a connection setup state. An accessterminal may be any data device that communicates through a wirelesschannel or through a wired channel, for example using fiber optic orcoaxial cables. An access terminal may further be any of a number oftypes of devices including but not limited to PC card, compact flash,external or internal modem, or wireless or wireline phone. Thecommunication link through which the access terminal sends signals tothe modem pool transceiver is called a reverse link or traffic channel.The communication link through which a modem pool transceiver sendssignals to an access terminal is called a forward link or trafficchannel. As used herein the term traffic channel can refer to either aforward or reverse traffic channel.

FIG. 1 illustrates a block diagram of one exemplary embodiment of awireless system 100 in accordance with at least one embodiment of theinvention. System 100 can contain access terminals, such as cellulartelephone 102, in communication across an air interface 104 with anaccess network or radio access network (RAN) 120 that can connect theaccess terminal 102 to network equipment providing data connectivitybetween a packet switched data network (e.g., an intranet, the Internet,and/or carrier network 126) and the access terminals 102, 108, 110, 112.As shown here, the access terminal can be a cellular telephone 102, apersonal digital assistant 108, a pager 110, which is shown here as atwo-way text pager, or even a separate computer platform 112 that has awireless communication portal. Embodiments of the invention can thus berealized on any form of access terminal including a wirelesscommunication portal or having wireless communication capabilities,including without limitation, wireless modems, PCMCIA cards, personalcomputers, telephones, or any combination or sub-combination thereof.Further, as used herein, the terms “access terminal”, “wireless device”,“client device”, “mobile terminal” and variations thereof may be usedinterchangeably.

Referring back to FIG. 1, the components of the wireless network 100 andinterrelation of the elements of the exemplary embodiments of theinvention are not limited to the configuration illustrated. System 100is merely exemplary and can include any system that allows remote accessterminals, such as wireless client computing devices 102, 108, 110, 112to communicate over-the-air between and among each other and/or betweenand among components connected via the air interface 104 and RAN 120,including, without limitation, carrier network 126, the Internet, and/orother remote servers.

The RAN 120 controls messages (typically sent as data packets) sent to abase station controller/packet control function (BSC/PCF) 122. TheBSC/PCF 122 is responsible for signaling, establishing, and tearing downbearer channels (i.e., data channels) between a packet data serving node100 (“PDSN”) and the access terminals 102/108/110/112. If link layerencryption is enabled, the BSC/PCF 122 also encrypts the content beforeforwarding it over the air interface 104. The function of the BSC/PCF122 is well-known in the art and will not be discussed further for thesake of brevity. The carrier network 126 may communicate with theBSC/PCF 122 by a network, the Internet and/or a public switchedtelephone network (PSTN). Alternatively, the BSC/PCF 122 may connectdirectly to the Internet or external network. Typically, the network orInternet connection between the carrier network 126 and the BSC/PCF 122transfers data, and the PSTN transfers voice information. The BSC/PCF122 can be connected to multiple base stations (BS) or modem pooltransceivers (MPT) 124. In a similar manner to the carrier network, theBSC/PCF 122 is typically connected to the MPT/BS 124 by a network, theInternet and/or PSTN for data transfer and/or voice information. TheMPT/BS 124 can broadcast data messages wirelessly to the accessterminals, such as cellular telephone 102. The MPT/BS 124, BSC/PCF 122and other components may form the RAN 120, as is known in the art.However, alternate configurations may also be used and the invention isnot limited to the configuration illustrated. For example, in anotherembodiment the functionality of the BSC/PCF 122 and one or more of theMPT/BS 124 may be collapsed into a single “hybrid” module having thefunctionality of both the BSC/PCF 122 and the MPT/BS 124.

FIG. 2A illustrates the carrier network 126 according to an embodimentof the present invention. In the embodiment of FIG. 2A, the carriernetwork 126 includes a packet data serving node (PDSN) 160, a broadcastserving node (BSN) 165, an application server 170 and an Internet 175.However, application server 170 and other components may be locatedoutside the carrier network in alternative embodiments. The PDSN 160provides access to the Internet 175, intranets and/or remote servers(e.g., application server 170) for mobile stations (e.g., accessterminals, such as 102, 108, 110, 112 from FIG. 1) utilizing, forexample, a cdma2000 Radio Access Network (RAN) (e.g., RAN 120 of FIG.1). Acting as an access gateway, the PDSN 160 may provide simple IP andmobile IP access, foreign agent support, and packet transport. The PDSN160 can act as a client for Authentication, Authorization, andAccounting (AAA) servers and other supporting infrastructure andprovides mobile stations with a gateway to the IP network as is known inthe art. As shown in FIG. 2A, the PDSN 160 may communicate with the RAN120 (e.g., the BSC/PCF 122) via a conventional A10 connection. The A10connection is well-known in the art and will not be described furtherfor the sake of brevity.

Referring to FIG. 2A, the broadcast serving node (BSN) 165 may beconfigured to support multicast and broadcast services. The BSN 165 willbe described in greater detail below. The BSN 165 communicates with theRAN 120 (e.g., the BSC/PCF 122) via a broadcast (BC) A10 connection, andwith the application server 170 via the Internet 175. The BCA10connection is used to transfer multicast and/or broadcast messaging.Accordingly, the application server 170 sends unicast messaging to thePDSN 160 via the Internet 175, and sends multicast messaging to the BSN165 via the Internet 175.

Generally, as will be described in greater detail below, the RAN 120transmits multicast messages, received from the BSN 165 via the BCA10connection, over a broadcast channel (BCH) of the air interface 104 toone or more access terminals 200.

FIG. 2B illustrates an example of the wireless communication 100 of FIG.1 in more detail. In particular, referring to FIG. 2B, ATs 1 . . . N areshown as connecting to the RAN 120 at locations serviced by differentpacket data network end-points. Accordingly, ATs 1 and 3 connect to theRAN 120 at a portion served by a first packet data network end-point 162(e.g., which may correspond to PDSN 160, BSN 165, a home agent (HA), aforeign agent (FA), etc.). The first packet data network end-point 162in turn connects, via the routing unit 188, to the Internet 175 and/orto one or more of an authentication, authorization and accounting (AAA)server 182, a provisioning server 184, an Internet Protocol (IP)Multimedia Subsystem (IMS)/Session Initiation Protocol (SIP)Registration Server 186 and/or the application server 170. ATs 2 and 5 .. . N connect to the RAN 120 at a portion served by a second packet datanetwork end-point 164 (e.g., which may correspond to PDSN 160, BSN 165,FA, HA, etc.). Similar to the first packet data network end-point 162,the second packet data network end-point 164 in turn connects, via therouting unit 188, to the Internet 175 and/or to one or more of the AAAserver 182, a provisioning server 184, an IMS/SIP Registration Server186 and/or the application server 170. AT 4 connects directly to theInternet 175, and through the Internet 175 can then connect to any ofthe system components described above.

Referring to FIG. 2B, ATs 1, 3 and 5 . . . N are illustrated as wirelesscell-phones, AT 2 is illustrated as a wireless tablet-PC and AT 4 isillustrated as a wired desktop station. However, in other embodiments,it will be appreciated that the wireless communication system 100 canconnect to any type of AT, and the examples illustrated in FIG. 2B arenot intended to limit the types of ATs that may be implemented withinthe system. Also, while the AAA server 182, the provisioning server 184,the IMS/SIP registration server 186 and the application server 170 areeach illustrated as structurally separate servers, one or more of theseservers may be consolidated in at least one embodiment of the invention.

Further, referring to FIG. 2B, the application server 170 is illustratedas including a plurality of media control complexes (MCCs) 1 . . . N170B, and a plurality of regional dispatchers 1 . . . N 170A.Collectively, the regional dispatchers 170A and MCCs 170B are includedwithin the application server 170, which in at least one embodiment cancorrespond to a distributed network of servers that collectivelyfunctions to arbitrate communication sessions (e.g., half-duplex groupcommunication sessions via IP unicasting and/or IP multicastingprotocols) within the wireless communication system 100. For example,because the communication sessions arbitrated by the application server170 can theoretically take place between ATs located anywhere within thesystem 100, multiple regional dispatchers 170A and MCCs are distributedto reduce latency for the arbitrated communication sessions (e.g., sothat a MCC in North America is not relaying media back-and-forth betweensession participants located in China). Thus, when reference is made tothe application server 170, it will be appreciated that the associatedfunctionality can be enforced by one or more of the regional dispatchers170A and/or one or more of the MCCs 170B. The regional dispatchers 170Aare generally responsible for any functionality related to establishinga communication session (e.g., handling signaling messages between theATs, scheduling and/or sending announce messages, etc.), whereas theMCCs 170B are responsible for hosting the communication session for theduration of the call instance, including conducting an in-call signalingand an actual exchange of media during an arbitrated communicationsession. Accordingly, in another embodiment of the invention, the MCCs170B may be referred to as PTT application servers and/or PTTmedia-distribution servers, assuming the arbitrated communicationsessions correspond to PTT calls.

Referring to FIG. 3, an access terminal 200, (here a wireless device),such as a cellular telephone, has a platform 202 that can receive andexecute software applications, data and/or commands transmitted from theRAN 120 that may ultimately come from the carrier network 126, theInternet and/or other remote servers and networks. The platform 202 caninclude a transceiver 206 operably coupled to an application specificintegrated circuit (“ASIC” 208), or other processor, microprocessor,logic circuit, or other data processing device. The ASIC 208 or otherprocessor executes the application programming interface (“API’) 210layer that interfaces with any resident programs in the memory 212 ofthe wireless device. The memory 212 can be comprised of read-only orrandom-access memory (RAM and ROM), EEPROM, flash cards, or any memorycommon to computer platforms. The platform 202 also can include a localdatabase 214 that can hold applications not actively used in memory 212.The local database 214 is typically a flash memory cell, but can be anysecondary storage device as known in the art, such as magnetic media,EEPROM, optical media, tape, soft or hard disk, or the like. Theinternal platform 202 components can also be operably coupled toexternal devices such as antenna 222, display 224, push-to-talk button228 and keypad 226 among other components, as is known in the art.

Accordingly, an embodiment of the invention can include an accessterminal including the ability to perform the functions describedherein. As will be appreciated by those skilled in the art, the variouslogic elements can be embodied in discrete elements, software modulesexecuted on a processor or any combination of software and hardware toachieve the functionality disclosed herein. For example, ASIC 208,memory 212, API 210 and local database 214 may all be used cooperativelyto load, store and execute the various functions disclosed herein andthus the logic to perform these functions may be distributed overvarious elements. Alternatively, the functionality could be incorporatedinto one discrete component. Therefore, the features of the accessterminal in FIG. 3 are to be considered merely illustrative and theinvention is not limited to the illustrated features or arrangement.

The wireless communication between the access terminal 102 and the RAN120 can be based on different technologies, such as code divisionmultiple access (CDMA), WCDMA, time division multiple access (TDMA),frequency division multiple access (FDMA), Orthogonal Frequency DivisionMultiplexing (OFDM), the Global System for Mobile Communications (GSM),or other protocols that may be used in a wireless communications networkor a data communications network. The data communication is typicallybetween the client device 102, MPT/BS 124, and BSC/PCF 122. The BSC/PCF122 can be connected to multiple data networks such as the carriernetwork 126, PSTN, the Internet, a virtual private network, and thelike, thus allowing the access terminal 102 access to a broadercommunication network. As discussed in the foregoing and known in theart, voice transmission and/or data can be transmitted to the accessterminals from the RAN using a variety of networks and configurations.Accordingly, the illustrations provided herein are not intended to limitthe embodiments of the invention and are merely to aid in thedescription of aspects of embodiments of the invention.

If a given access terminal (AT) has a large amount of data to send to aparticular target, the set-up time of the file-transfer session is ofrelatively low importance because the time related to the file-transfersession will be relatively high as compared to the set-up time of thefile-transfer session. However, the set-up time for file-transfersessions where a relatively small amount of data is exchanged can bedisproportionately high as compared to the duration of the sessionitself.

FIG. 4A illustrates a conventional manner by which a file can beexchanged between ATs in a communication system. In particular, FIG. 4Aillustrates a conventional example of how a transmitting AT sends a fileto a target AT when the transmitting AT is already engaged in acommunication session.

Referring to FIG. 4A, a given AT (“AT 1”) determines whether to initiatea file-transfer session, 400A. If AT 1 determines not to initiate thefile-transfer session, then AT 1 does not set-up resources for acommunication session and the process remains in 400A.

Otherwise, if AT 1 determines to initiate the file-transfer session, AT1 sets up a TCH with the RAN 120 for the file-transfer session, 405A.Then, once obtaining the TCH for the file-transfer session, AT 1 sets-upits transport connection for the file-transfer session by engaging in a3-way TCP handshake in order to obtain a data-port for exchanging dataduring the file-transfer session with the application server 170, 410A.TCP is well-known in the art and uses standard network layeringprotocols. Generally, before a client such as AT 1 attempts to connectwith a server such as the application server 170, the server must firstbind to a port to open the client up for connections, which is referredto a ‘passive open’. Once the passive open is established, a client mayinitiate an ‘active open’. To actually establish the transport or TCPconnection, the three-way (or 3-step) handshake occurs whereby theactive open is performed by the client sending a SYN to the server, theserver replies with a SYN-ACK and the client sends an ACK back to theserver. At this point the client, which is AT 1 in this case, hasactivated its transport connection with the application server 170 andhas a data port with which to tag messages to the application server170. While not shown explicitly in FIG. 4A, the above-describedTCP-handshake also occurs at the target-side for the communicationsession. The set-up that occurs at the target side is described belowwith respect to FIG. 4B.

After setting up the transport connection, AT 1 can set-up theapplication that handles the file-transfer session at AT 1 and can beginsending application-layer data (i.e., the file to be transferred) to theapplication server 170 for transmission to AT 2, 415A. The AT 1 canperiodically determine whether the file(s) to be transferred during thefile-transfer session have been successfully sent to the applicationserver 170 for transmission to AT 2, 420A. If AT 1 determines that oneor more files or file-portions have not yet completed their transmissionin 420A, the process returns to 415A and AT 1 continues to send file(s)or file-portions to the application server 170 for transmission to AT 2using the resources obtained in 405A and 410A. Otherwise, the processadvances to 425A after the transfer of all files for the file-transfersession of 415A complete their transmission

In 425A, AT 1 releases the session resources obtained for the datatransmission of 415A, such that the TCH from 405A is torn-down and thetransport connection of 410A is terminated. At some later point in time,AT 1 determines whether to send any additional files to AT 2, 430A. Ifso, the process returns to 405A so that AT 1 can again obtain sessionresources (e.g., a TCH, a transport connection, etc.) and send one ormore file(s) during another file-transfer session to AT 2.

FIG. 4B illustrates a conventional manner by which a file can beexchanged between ATs in a communication system. In particular, FIG. 4Aillustrates a conventional example of how a target AT receives a filefrom a transmitting AT. FIG. 4B shows a process that can occur at thetarget AT or AT 2 during the process of FIG. 4A, in an example.

Referring to FIG. 4B, after the application server 170 is notified thatAT 1 will be sending data to be forwarded to AT 2, the applicationserver 170 sends an Open message (e.g., a page message) to the RAN 120,401B, which is then transmitted by the RAN 120 to AT 2, 402B. AT 2receives the Open message and begins to set-up a traffic channel (TCH),405B. Next, in 410B, AT 2 sets up a transport connection via a TCPhandshake, similar to the process that occurs at AT 1 in 410A.

At some point during this process, AT 1 begins sending data in 415A tothe application server 170 via its established data port for thecommunication session. The application server 170 begins buffering thedata from AT 1 in 416B because the TCP handshake with AT 2 is not yetcomplete and/or the application server 170 is required to send datapackets in-sequence and the packets can arrive out-of-order. Once AT 2completes the TCH-handshake by ACKing the SYN-ACK message, theapplication server 170 can begin forwarding the buffered data to AT 2,420B. However, it will be appreciated that the buffering of 416B doesnot necessarily end the instant the ACK is received, and can continuefor a period of time.

As will be appreciated, the data packets that arrive at the applicationserver 170 in 415A may be out of order or out of sequence due to loss inthe wireless link. Therefore, the application server 170 will buffer allthe packets in 416B. After the data port is established with AT 2, theapplication server 170 can begin to deliver the buffered data packets toAT 2, 420B. Conventionally, only consecutive packets from 1 to p can bedelivered to AT 2 even if n−1 packets are available because packet p+1is still missing. This is known in the art as ‘head-of-line blocking’and is a problem in conventional TCP. As will be described below in moredetail, in at least one embodiment of the invention, head-of-lineblocking can be reduced and/or eliminated. Thus, delays associated withFIGS. 4A and/or 4B occur in part because files in TCP enforces thatfiles be delivered in order or in sequence.

As will be appreciated, a relatively long time can occur between thetime AT 1 determines to initiate the file-transfer session in 400A tothe time when AT 1 is able to begin sending data packets for thefile-transfer session in 415A. For example, it can take approximately300 ms to set-up the TCH, and it can then take additional time to set-upthe transport connection. Accordingly, embodiments of the invention aredirected to permitting an AT to begin transmitting data for afile-transfer session more quickly when the AT is concurrently engagedin a previously-established communication session (e.g., a VoIP session,etc.).

FIGS. 4C and 4D illustrate signaling associated with set-up of afile-transfer session between an originating AT 1 and a target AT 2 inaccordance with an embodiment of the invention. Specifically, FIG. 4Cfocuses upon the signaling that occurs between AT 1 and the applicationserver 170 during the set-up of the file-transfer session, and FIG. 4Dfocuses upon the signaling that occurs between the application server170 and AT 2 during the set-up of the file-transfer session.

Referring to FIG. 4C, a given AT (“AT 1”) determines whether to initiatea file-transfer session, 400C. If AT 1 determines not to initiate thefile-transfer session, then the process remains in 400C. Otherwise, ifAT 1 determines to initiate the file-transfer session, AT 1 determineswhether a communication session that has already been established by AT1 has access to session resources that are currently available for thetransmission of the file(s) for the file-transfer session, 405C. Forexample, if AT 1 is already engaged in another file-transfer session in405C, then AT 1 can simply use the TCH and transport connection of theother file-transfer session for the newly initiated file-transfersession. Otherwise, if existing session resources are not available forthe file-transfer session, the process advances to 410C.

Referring to FIG. 4C, AT 1 begins setting-up a TCH with the RAN 120 forthe file-transfer session, 410C. Unlike FIG. 4A, in 415C, instead ofwaiting for the TCH to complete set-up, AT 1 instead preemptively beginsset-up of the transport connection and application-layer connection byconfiguring a data-over-signaling (DoS) message to include transportdata and application data, and then sending the DoS message on a reverselink access channel to the RAN 120, which forwards the DoS message tothe application server 170. In an example, the DoS message transmittedin 415C can use a signaling or DoS port that has already been set-up forsignaling messages of AT 1. For example, certain ATs can bepreconfigured with DoS ports by a service provider (e.g., Sprint,Verizon, etc.) before being provisioned to end-users of the ATs.Thereafter, the ATs are permitted to use their associated DoS port solong as coverage can be provided by the RAN 120.

Accordingly, AT 1 leverages the previously established signaling port toset-up the transport and application-layer connections for thefile-transfer session in 415C. The application server 170 recognizesspecific information (e.g., a message being delivered on a differentport than the port that is being used to send the data, such as thesignaling port) the contained in the DoS message in 415C, determines AT1 is attempting to set-up a transport connection in order to send datato AT 2 during a file-transfer session. Accordingly, the applicationserver 170 uses the transport-layer parameters contained in the DoSmessage from 415C to select a data port for AT 1 to use during thefile-transfer session, 417C.

The application server 170 sends a Start message to AT 2 in 401D toinstruct AT 2 to prepare for the file-transfer session. 401D isdiscussed in more detail below with respect to FIG. 4D, which coverssignaling between the application server 170 and the target AT 2 in moredetail.

At some later point in time, assume that AT 1 completes its TCH set-up,420C. AT 1 also receives a reply, from the application server 170, tothe DoS message of 415C on the data port that is set-up for AT 1 in417C, 425C. At this point, AT 1 begins sending data to the applicationserver 170 to be forwarded to AT 2 on the data port, 430C. As will beappreciated, the initial data message, 431C, that is sent on the dataport over the TCH to the RAN 120 to be forwarded to the applicationserver 170 functions as an ACK to the reply message from 425C, such thatAT 1 need not send an explicit ACK to the reply message. The applicationserver 170 forwards the data from AT 1 to AT 2 in 445D (e.g., afterbuffering the data for a period of time until AT 2 is prepared toreceive the data), which is discussed in more detail below with respectto FIG. 4D.

As discussed above, the DoS message of 415C can function as a SYNmessage. Thereafter, the Reply message of 425C can function as a SYN-ACKmessage, and AT 1 can complete set-up of the data port by sending dataon the data port in 430C and 431C, which functions to ACK the replymessage. Accordingly, 415C, 425C and 431C collectively correspond to adifferent manner of performing the TCP-handshaking that is shown in 415Aof FIG. 4A, whereby the transport connection can begin set-up before aTCH is obtained.

In an example, the TCP SYN message (e.g., shown in 410A of FIG. 4A) canbe embedded within the DOS message of 415C. The key contents of the TCPSYN message include the source and destination ports and the initialsequence number. The application server 170 can respond with a SYN_ACKmessage (e.g., which can be embedded in the reply message of 425C, whichis discussed below in more detail) or can encode the key contents of theSYN ACK message (e.g., the source and destination ports and the initialsequence number) in another message sent to AT 1, such as an ACK to acall request message (e.g., a Call-ACK message over user datagramprotocol (UDP)). In either case, the TCP transport connection for AT 1'sfile-transfer session leverages the signaling session parameters thatare typically used for an application-layer communication session (e.g.,a multimedia session between two or more participants). By initiatingset-up of the transport connection in 415C, the SYN message can becommunicated more quickly to the application server 170, andconsequently the set-up of the TCP connection can occur more quickly foran end-to-end call between participants. In other words, delayassociated with performing the a-way handshake for setting up the TCPconnection (as in 410A of FIG. 4A) is reduced in the embodiment of FIG.4C.

The reply message of 425C is sent on the data port instead of thesignaling port, and after the reply message (e.g., containinginformation similar to a SYN-ACK message) is sent in 425C, AT 1 canbegin to use the data port for transmissions of data during thefile-transfer session. Accordingly, by concurrently initiating processesfor bringing up the TCH and obtaining a transport connection for thefile-transfer session, AT 1 can more quickly begin sendingapplication-layer data for the file-transfer session. As noted abovewith respect to FIG. 4C, the data packets sent in 430C and 431C mayarrive at the application server 170 out of order due to loss in thewireless link. The application server 170 will buffer all the packets inthis case. Conventionally, only consecutive packets from 1 to p can bedelivered to AT 2 even if n−1 packets are available because packet p+1is still missing. This is known in the art as ‘head-of-line blocking’and is a problem in conventional TCP. As will be described below in moredetail, in at least one embodiment of the invention, head-of-lineblocking can be reduced and/or eliminated (e.g., when the data portcorresponds to UDP, blocking is eliminated altogether). For example, aswill be discussed below in more detail, buffering may only continueuntil a reply message is received from target AT 2 at 440D of FIG. 4D,as compared to conventional FIGS. 4A and 4B whereby buffering occursuntil a given file completes its transfer.

AT 1 can periodically determine whether the file(s) to be transferredduring the file-transfer session have been successfully sent to theapplication server 170 for transmission to AT 2, 440C. If AT 1determines that one or more files or file-portions have not yetcompleted their transmission in 440C, the process returns to 430C and AT1 continues to send file(s) or file-portions to the application server170 for transmission to AT 2. Otherwise, the process advances to 445Cafter the transfer of all files for the file-transfer session of 430Ccomplete their transmission. In 445C, AT 1 determines whether to sendany additional files to AT 2. If so, the process returns to 430C, and AT1 re-uses the session resources established during 410C through 435C forthe previous file-transfer session to send one or more file(s) duringanother file-transfer session to AT 2. Otherwise, if AT 1 determines nomore data requires transmission to AT 2 in 445C, AT 1 releases thesession resources obtained for the data transmission of 430C and 431C,such that the TCH from 410C and 420C is torn-down and the transportconnection (i.e., data port) is terminated.

As will be appreciated from a review of FIG. 4C, the signaling port isused to send the SYN-message (or equivalent information), and thereafterdata is sent to the application server 170 via the data port. Thus, thetransport connection is set-up on a different port than the port beingset-up for the actual session.

FIG. 4D illustrates operations that occur between the application server170 and the target AT 2 during the process of FIG. 4C in accordance withan embodiment of the invention. In particular, FIG. 4D illustrates thesignaling between the application server 170 and the target AT 2 between401D and 445D of FIG. 4C.

Referring to FIG. 4D, upon receiving the Start message from AT 1 in 415Cof FIG. 4C, the application server 170 identifies and locates eachintended target for the file-transfer session, and then sends a Startmessage to each identified and located target, 401D. In FIG. 4D, forconvenience of explanation, a single target AT 2 is shown. The Startmessage(s) of 401D includes transport data, such as timer delays andmessage window sizes, along with some application data such as adesignation of a port upon which the application server 170 expects toreceive data from AT 2. As will be appreciated, the data port(s)allocated to the target(s) of the file-transfer session need not be thesame as the data-port allocated to AT 2. The Start message of 401D issent over a signaling port, such as a DoS port. Accordingly, the Startmessage can correspond to a mobile-termination (MT)-DoS message,contrasted with a mobile-originated (MO) DoS message as in 415C from AT1.

Upon receiving the Start message, AT 2 determines whether AT 2 isalready engaged in an existing communication session, such that AT 2already has a TCH, 410D. If AT 2 determines that AT 2 does not yet havea TCH in 410D, AT 2 brings up a TCH in 415D.

Turning back to AT 1, after AT 1 obtains a data port (e.g., after AT 1receives the reply message in 425C of FIG. 4C), AT 1 begins sending datato the application server 170 on the data port, 430D. In FIG. 4D, 431Ccorresponds to the initial data packet sent over the data port from AT1, and 431C of FIG. 4D also corresponds to the like-numbered signaldiscussed above with respect to FIG. 4C.

In the embodiment of FIG. 4D, it is assumed that data from AT 1 intendedfor AT 2 begins arriving at the application server 170 on AT 1's dataport before AT 2 is prepared to receive the data. Accordingly, theapplication server 170 begins buffering the data from AT 1 in 425D, andthe application server 170 continues to buffer the data in 425D at leastuntil AT 2 indicates its readiness to download the data from theapplication server 170.

After setting up the TCH in 415D or confirming that AT 2 already had aTCH in 410D, AT 2 sends a reply message to the application server 170,440D. The reply message of 440C includes information such as the port AT2 is using for the file-transfer session. Upon receiving the replymessage from AT 2, the application server 170 knows the data port usedby AT 2 for the file-transfer session, and thereby begins sending thebuffered data of 425C to AT 2, 445D.

While not shown in FIG. 4D, it is possible that the reply message of440D can arrive at the application server 170 before the data from AT 1arrives at the application server 170 in 431C. For example, if AT 1starts the process of FIG. 4C without a TCH and AT 2 starts the processof FIG. 4D with a TCH, AT 2 may be able to respond to the Start messagemore quickly than AT 1 can set up its own TCH and start sending data. Inthis case, the application server 170 need not perform the buffering of425D, and rather can begin forwarding the data from AT 1 to AT 2 as soonas the data from AT 1 begins to arrive at the application server 170.

While FIGS. 4C-4D relate to how a file-transfer session can be set-up,another aspect to file-transfer sessions in wireless communicationsystems is the interaction between different functional layers of anoriginating or target access terminal. In FIGS. 5A through 5D,references are made to functional layers “1”, “2” and “3” of AT 1. Thesedifferent functional layers correspond to a combination of softwareand/or hardware that is responsible for performing a particular functionat different layers. However, while the embodiments described belowfocus upon three (3) functional layers for convenience of explanation,it will be appreciated that the embodiments are not restricted to 3functional layers and can instead include any number of functionallayers.

In an example, functional layer 1 can be referred to as a MAC layer,functional layer 2 can be referred to as a transport-layer, andfunctional layer 3 can be referred to as an application-layer.Functional layer 1 is characterized as having a transmission window ortransmission queue that holds data packets queued for transmission on areverse-link physical layer channel to the RAN 120. Functional layer 2can request certain packets to be added to the transmission window offunctional layer 1, and these packets can actually be generated at ahigher-level or higher-layer by functional layer 3.

In an example, functional layer 3 can correspond to an application-layerinterface such as a session initiation protocol (SIP) client or anyother multimedia application layer interface process. A SIP client forinstance, may be responsible for managing application-layerfunctionality of a media application (e.g., a VoIP application, a PTTapplication, etc.), a transport layer protocol, and a lower-layercontroller (e.g., a controller of a radio link control (RLC) layer inW-CDMA systems, a controller of a radio link protocol (RLP) layer inEV-DO systems, etc.).

Generally, when functional layer 3 has data to send to another sessionparticipant (e.g., AT 2), functional layer 3 requests functional layer 2to send the data, which in turn requests functional layer 1 to send thedata on the physical-channel. However, because functional layer 3 doesnot have direct control with regard to when the data is actuallytransmitted, functional layer 3 cannot determine when the data is senton the physical-channel by functional layer 1. Thus, the functionallayer 3 typically tracks when it issues data-packet transmissioncommands to functional layer 2, but does not track when functional layer1 transmits the actual data packet on the physical layer (i.e., over thewireless interface 104).

Referring to FIG. 5A, assume AT 1 sets up and begins participation in acommunication session (e.g., a streaming media session, a file-transfersession, etc.) with at least one other session participant, 500A. Next,functional layer 3 issues a request to functional layer 2 to transmit anew data packet for the communication session be sent to the applicationserver 170 and then to the at least one other session participant, 505A.After requesting functional layer 2 to transmit the new data packet,functional layer 3 starts an expiration timer having a given expirationperiod. While the expiration timer is running, functional layer 3 waitsto receive an ACK of the transmitted data packet, whereby functionallayer 3 will infer that the transmission of the data packet was notsuccessful if no ACK is received before the expiration timer expires,510A.

Functional layer 2 receives the request for transmission of the new datapacket and adds the data packet to a transmission queue or windowmaintained by functional layer 2, 515A, after which functional layer 2instructs functional layer 1 to attempt to transmit all of the datapackets that are currently scheduled in the transmission window offunctional layer 2, 520A. As will be appreciated, not all embodiments ofthe invention require the functional layer 2 to have its owntransmission window or queue. If functional layer 2 did not have such atransmission window, functional layer 2 could simply add the data packetrequested for transmission in 505A into the transmission window offunctional layer 1 each time a new data packet is requested fortransmission by functional layer 3. Accordingly, while functional layer2 does not necessarily have its own transmission queue, the embodimentsof FIGS. 5A through 5D are described under the assumption thatfunctional layer 2 has access to its own transmission queue. It will bereadily appreciated by one of ordinary skill in the art how FIGS. 5Athrough 5D can be modified to accommodate the lack of a transmissionqueue at functional layer 2 in other embodiments of the invention.

Functional layer 1 receives the transmission order from functional layer2, and then adds the data packets from the transmission window offunctional layer 2 to its own transmission window, 525A. At 530A,functional layer 1 makes one or more attempts to transmit the datapackets contained in the transmission window of functional layer 1. In530A, when a transmission attempt of one of the data packets in thetransmission window of functional layer 1 is not successful, functionallayer 1 adds the unsuccessfully transmitted data packets back to thetransmission window of functional layer 1 a given number of times untilthe data packet(s) are sent successfully. Accordingly, 535A shows thedata packet being added back to the transmission window of functionallayer 1 resulting in its successful transmission. As will be appreciatedby one of ordinary skill in the art, functional layer 3 is not notifiedwith regard to whether these individual attempts to send the data packetare successful or unsuccessful. After the successful transmission of thedata packet in 535A, the Application Server 170 acknowledges thesuccessful receipt of the data packet by sending a function layer−3 ACKmessage back to AT 1, 540A.

While the above-described data packet transmission process is ongoing atfunctional layer 1, functional layer 3 is not actually aware of theactions taking place at functional layer 1, and functional layer 3simply monitors whether an ACK to the data packet requested fortransmission in 505A has been received at functional layer 3.Accordingly, in 545A, functional layer 3 determines whether an ACK tothe requested data packet from 505A has been received before theexpiration timer expires. If functional layer 3 determines that the datapacket has been successfully ACKed in 545A, the process advances to560A. Otherwise, if functional layer 3 determines that the data packethas not been successfully ACKed in 545A, functional layer 3 inferstransmission failure for the data packet, and issues another request tothe transport layer protocol for transmitting the data packet again,550A. In the embodiment of FIG. 5A, the ACK in 540A is received afterthe expiration of the expiration timer, such that functional layer 3 hasalready determined that its data packet has not been ACKed successfullyin 545A.

Accordingly, functional layer 2 receives the new request for thetransmission of the data packet, and again adds the data packet to thetransmission window of functional layer 2, 555A. At this point, theprocess returns to 520A and repeats for the new request for transmissionof the data packet by functional layer 1. As will be appreciated, eventhough functional layer 1 has continued to attempt to send the datapacket, functional layer 3 is only aware that the expiration timer hasexpired which triggers the new request for the data packet'stransmission. This will then require functional layer 1 to send the datapacket to the application server 170 twice (i.e., once for each packettransmission request issued by functional layer 3 in 505A).

In the embodiment of FIG. 5A, when functional layer 3 determines thatone of the data packets it has requested for transmission has beensuccessfully ACKed by the application server 170 in 545A, functionallayer 3 then determines whether more data is to be requested fortransmission to the application server 170, 560A. If functional layer 3determines to transmit more data to the application server 170 in 560A,the process returns to 505A and repeats for the transmission of one ormore additional data packets. Otherwise, the process of FIG. 5Aterminates, although the communication session of 500A could continuewith AT 1 receiving data packets without sending data packets for aperiod of time.

An embodiment of the invention directed to a mechanism by whichfunctional layer 3 and functional layer 1 can exchange informationrelated to the status of a packet awaiting transmission at functionallayer 1 will now be described with respect to FIG. 5B.

Referring to FIG. 5B, assume AT 1 sets up and begins participation in acommunication session with at least one other session participant, 500B.Next, functional layer 3 requests that a new data packet for thecommunication session be sent to functional layer 2 for transmission tothe application server 170 and then to the at least one other sessionparticipant, 505B. However, unlike FIG. 5A, after requesting functionallayer 2 to send the new data packet in 505B, functional layer 3 does notyet start the expiration timer that defines a time period during whichfunctional layer 3 will wait for the ACK to the data packet.

Next, 510B through 530B of FIG. 5B generally correspond to 515A through535A, respectively, of FIG. 5A, and as such will not be described infurther detail for the sake of brevity. After functional layer 1successfully transmits the data packet to the RAN 120 on thephysical-layer in 530B, the RAN 120 sends a layer 1-ACK to functionallayer 1 of AT 1, 534B, after which functional layer 1 sends anotification message to functional layer 3 that indicates that the datapacket requested for transmission in 505B has been transmitted from AT1, 535B. For example, the notification message from functional layer 1to functional layer 3 may be implemented as a call-back API. While notshown explicitly in FIG. 5B, the notification of 535B can be performedfor each data packet that has been requested for transmission byfunctional layer 3 when the respective data packets are transmitted fromAT 1 at functional layer 1.

Functional layer 3 conventionally starts the expiration timer whenfunctional layer 3 itself requests the data packet transmission, whichdoes not take into account delays at functional layers 2 and/or 1 beforethe data packet can be transmitted from AT 1. In the embodiment of FIG.5B, upon receiving the notification of data packet transmission atfunctional layer 3 in 535B, functional layer 3 starts the expirationtimer in 540B, instead of when the data packet transmission request isissued in 505B. As will be appreciated by one of ordinary skill in theart, starting the expiration period at this later point in time reducesthe chance that functional layer 3 will re-issue requests to transmitthe same data packet due to delays at functional layers 2 and/or 1 of AT1 that occur prior to the transmission of the data packet. Also,throughput need not be degraded except in an edge scenario. Further, itwill be appreciated that while the expiration timer started in 540B isshown as running for a shorter period of time than the expiration timerin 510A, the actual expiration periods for the times of 510A and 540Bcan be the same. However, because the expiration timer in 540B starts ata later point in time, the expiration timer of 540B can run for ashorter period because an ACK will be more quickly received subsequentto the start of the timer.

Turning back to functional layer 1, after the successful transmission ofthe data packet in 530B, the Application Server 170 acknowledges thesuccessful receipt of the data packet by sending a layer−3 or SIP-layerACK message back to AT 1, 545B.

In 550B, functional layer 3 determines whether an ACK to the requesteddata packet from 505B and transmitted from AT 1 at 530B has beenreceived before the expiration timer expires. Again, the expirationtimer in FIG. 5B starts after the notification of 535B instead ofearlier when the actual data packet transmission request is issued fromfunctional layer 3 at 505B, which generally means the expiration timerof FIG. 5B will grant the Application Server 170 a longer timer to ACKan initial data packet's transmission before a repeat-transmission isrequested by functional layer 3. If functional layer 3 determines thatthe data packet has been successfully ACKed in 550B, the processadvances to 565B. Otherwise, if functional layer 3 determines that thedata packet has not been successfully ACKed in 550B, functional layer 3infers transmission failure for the data packet, and issues anotherrequest to functional layer 2 for transmitting the data packet again,555B. Functional layer 2 receives the new request for the transmissionof the data packet, and again adds the data packet to the transmissionwindow of functional layer 2, 560B. At this point, the process returnsto 515B and repeats for the new request for transmission of the datapacket. In the example of FIG. 5B, it will be appreciated that thedecision block of 550B evaluates to the ACK from the Application Server170 being received within the expiration period based at least in partto functional layer 3 starting the expiration timer responsive to thenotification of 535B instead of the transmission request of 505B.

Accordingly, FIG. 5B is one example embodiment the demonstrates how thenumber of unnecessary repeated data packet transmission requests fromfunctional layer 3 can be reduced by implementing a mechanism by whichfunctional layer 1 can notify functional layer 3 with regard to when adata packet transmission over the wireless or physical layer to the RAN120 is successful. Accordingly, while FIGS. 5A-5B illustrate benefitsassociated with an early notification to functional layer 3 of thesuccessful physical-layer transmission of a given data packet, FIGS.5C-5D illustrate benefits associated with an early notification tofunctional layer 3 of the unsuccessful physical-layer transmission of agiven data packet.

Referring to FIG. 5C, assume AT 1 sets up and begins participation in acommunication session (e.g., a streaming media session, a file-transfersession, etc.) with at least one other session participant, 500C. Next,functional layer 3 issues a request to functional layer 2 fortransmission of a new data packet to the application server 170 and thento the at least one other session participant, 505C. After requestingfunctional layer 2 to send the new data packet, functional layer 3starts an expiration timer having a given expiration period, as in 510Aof FIG. 5A. While the expiration timer is running, functional layer 3waits to receive an ACK of the transmitted data packet, wherebyfunctional layer 3 will infer that the transmission of the data packetwas not successful if no ACK is received before the expiration timerexpires, 510C.

Functional layer 2 receives the request for transmission of the new datapacket and adds the data packet to a transmission window of functionallayer 2, 515C, after which functional layer 2 instructs functional layer1 to attempt to transmit all of the data packets that are currentlyscheduled in the transmission window of functional layer 2, 520C.Functional layer 1 receives the transmission order from functional layer2, and then adds the data packets from the transmission window offunctional layer 2 to its own transmission window, 525C. At 530C,functional layer 1 makes one or more attempts to transmit the datapackets contained in the transmission window of functional layer 1. In530C, when a transmission attempt of one of the data packets in thetransmission window of functional layer 1 is not successful, functionallayer 1 adds the unsuccessfully transmitted data packets back to thetransmission window of functional layer 1 a given number of times untilthe data packet(s) are sent successfully the number of repeatedtransmission attempts exceeds a threshold. Accordingly, 530C shows anunsuccessful attempt to transmit the data packet to the applicationserver, whereby the data packet is not sent successfully to the RAN 120.

Because the RAN 120 could not complete the transmission of the datapacket to the application server 170, the RAN 120 sends a layer−1negative ACK (NACK) to functional layer 1 of AT 1, 540C. Alternatively,an explicit NACK need not be sent by the RAN 120, in which casefunctional layer 1 will simply infer failure of the data packet'stransmission on the physical layer after a threshold period of timewithout an ACK being received from the RAN 120 (i.e., ACK-timeout).However, while functional layer 1 receives the NACK-frame or inferspacket-loss when no ACK is received, functional layer 1 does not notifyfunctional layer 3 that the attempted transmission of the data packethas already failed.

In the embodiment of FIG. 5C, while the above-described data packettransmission process is ongoing at functional layer 1, functional layer3 is not actually aware of the actions taking place at functional layer1, and functional layer 3 simply monitors whether an ACK to the datapacket requested for transmission in 505C has been received atfunctional layer 3. Accordingly, in 545C, functional layer 3 determineswhether an ACK to the requested data packet from 505C has been receivedbefore the expiration timer expires. If functional layer 3 determinesthat the data packet has been successfully ACKed in 545C, the processadvances to 560C. Otherwise, if functional layer 3 determines that thedata packet has not been successfully ACKed in 545C, functional layer 3infers transmission failure for the data packet, and issues anotherrequest to functional layer 2 for transmitting the data packet, 550C.Functional layer 2 receives the new request for the transmission of thedata packet, and again adds the data packet to the transmission windowof functional layer 2, 555C. At this point, the process returns to 520Cand repeats for the new request for transmission of the data packet.

As will be appreciated, even though functional layer 1 determinedpacket-failure or packet-loss in 540C (e.g., either from an explicitNACK or a failure to receive an ACK from the RAN 120), functional layer3 assumes the transmission failure only upon expiration of theexpiration timer in 545C. Accordingly, relying upon the expiration timerin FIG. 5A caused an unnecessary repeat-transmission of the data packetwhen the ACK arrived late, and relying upon the expiration timer in FIG.5C caused an unnecessary delay before ordering a repeat-transmission ofthe data packet when the transmission attempt actually fails.

Turning back to FIG. 5C, when functional layer 3 determines that one ofthe data packets it has requested for transmission has been successfullyACKed by the application server 170 in 545C, functional layer 3 thendetermines whether more data is to be requested for transmission to theapplication server 170, 560C. If functional layer 3 determines totransmit more data to the application server 170 in 560C, the processreturns to 505C and repeats for the transmission of one or moreadditional data packets. Otherwise, the process of FIG. 5C terminates,although the communication session of 500C could continue with AT 1receiving data packets without sending data packets for a period oftime.

An embodiment of the invention directed to a mechanism by whichfunctional layers 1 and 3 can exchange information related to the statusof a packet awaiting transmission at functional layer 1 will now bedescribed with respect to FIG. 5D.

Referring to FIG. 5D, assume AT 1 sets up and begins participation in acommunication session with at least one other session participant, 500D.Next, functional layer 3 requests that a new data packet for thecommunication session be sent to functional layer 2 for transmission tothe application server 170 and then to the at least one other sessionparticipant, 505D. However, unlike FIG. 5C, after requesting functionallayer 2 to send the new data packet in 505D, functional layer 3 does notyet start the expiration timer that defines a time period during whichfunctional layer 3 will wait for the ACK to the data packet.

Next, 510D through 530D of FIG. 5D generally correspond to 515C through535C, respectively, of FIG. 5C, and as such will not be described infurther detail for the sake of brevity. If functional layer 1 was ableto successfully transmit any data packets to the RAN 120 in 530B,functional layer 1 sends a notification message to functional layer 3that indicates that the data packet requested for transmission in 505Dhas been transmitted from AT 1, 535D, similar to 535B of FIG. 5B.However, soon after 535D, assume that the RAN 120 either sends a layer−1NACK for the data packet to functional layer 1 of AT 1, or alternativelyfunctional layer 1 infers packet-failure or packet-loss when the RAN 120fails to ACK the data packet, 540D. In FIG. 5C, the indication ofpacket-transmission failure at 540C resulted in the cessation ofsubsequent transmission attempts for the data packet. However, in FIG.5D, of indication of packet-transmission failure at 540D also results ina notification to functional layer 3 that the attempt to transmit thedata packet, which was indicated to functional layer 3 in 535D, hasfailed in 545D. Similar to the notifications of 535B of FIG. 5B and/or535D of FIG. 5D, the notification message from functional layer 1 tofunctional layer 3 in 545D may be implemented as a call-back API.

While not shown in FIG. 5D, functional layer 3 can start the expirationtimer upon receipt of the transmission-notification in 535D. However,upon the subsequent receipt of the notification of transmission-failurein 545D, functional layer 3 need not wait for this expiration timer toexpire and rather can infer upon that the data packet requiresre-transmission via the notification from functional layer 1.

Accordingly, responsive to the transmission-failure notification fromfunctional layer 1, functional layer 3 issues another request to thefunctional layer 2 for transmitting the data packet, 550D (e.g.,irrespective of whether an expiration timer corresponding to a period torefrain from re-issuing the data request transmission, or to wait forthe ACK, has expired). Functional layer 2 receives the new request forthe transmission of the data packet, and again adds the data packet tothe transmission window of functional layer 2, 555D. Functional layer 2then instructs functional layer 1 to attempt to transmit all of thepackets in the transmission window of functional layer 2, 560D.Functional layer 1 receives the transmission order from functional layer2, and then adds the data packets from the transmission window offunctional layer 2 to its own transmission window, 565D. At 570D, assumethat functional layer 1 successfully transmits the data packet to theRAN 120, and that the RAN 120 successfully forwards the data packet tothe application server 170. Accordingly, the Application Server 170acknowledges the successful receipt of the data packet by sending alayer−3 ACK message back to AT 1, 575D.

Upon receiving the ACK, functional layer 3 determines whether totransmit another data packet, 580D. If functional layer 3 determines totransmit another data packet, the process returns to 505D. Otherwise, iffunctional layer 3 determines not to transmit another data packet in580D, the process of FIG. 5D terminates, although the communicationsession of 500D could continue with AT 1 receiving data packets withoutsending data packets for a period of time.

While not shown explicitly in FIG. 5D in order to simplify the signalingdiagram, it will be appreciated that the repeated attempt to transmitthe data packet between 550D and 575D could also be associated with thenotifications of 535D and 545D, as appropriate. These notificationmessages are omitted for clarity, but it will be appreciated that atransmission-notification could be sent from functional layer 1 tofunctional layer 3 after 570D, for example, which could result in theexpiration timer being started at functional layer 3.

In a further example, referring to FIG. 5D, when using EnhancedMulti-flow Packet Application, the RLP layer (e.g., functional layer 1)performs the framing and de-framing of maximum transmission units(MTUs). If an RLP NACK is received at functional layer 1, the RLP layerupon retransmitting the packet a threshold number of times can indicateto the higher layer (e.g., functional layer 3) whether the MTU wastransmitted successfully or not (e.g., as in 535B of FIG. 5B or 535D ofFIG. 5D). In case RLP NACKs are disabled but a MTU is fragmented overmultiple RLP packets which are further segmented over Physical Layerpackets, then the loss of a segment can be inferred by Physical LayerNACKs. A RLP packet can be inferred as successful based on thesePhysical Layer NAKs. However, if even one of the physical layer segmentsis completely lost, then the MTU is lost and this information can beutilized by the higher layer to invoke retransmission of the MTU (e.g.,in other words, a NACK or packet transmission-failure to any packet‘segment’ can be used to infer a failure of the transmission of thewhole packet). Similar procedures can be accomplished in WCDMA physicallayers if the loss is deduced by the RLC layer. Accordingly, the NACK orpacket-transmission failure of 540D could be a NACK orpacket-transmission failure to any particular segment.

FIG. 6A illustrates a conventional mechanism of supporting afile-transfer session concurrently with a streaming or real-timecommunication session. Accordingly, referring to FIG. 6A, assume thatthe application server 170 sets up a first session corresponding to astreaming communication session (e.g., a VoIP session) between AT 1 andAT 2, 600A, and that the application server 170 then sets-up a secondsession corresponding to a file-transfer session to facilitate thetransfer of one or more files from AT 1 to AT 2, 605A. It may be furtherassumed that the first session of 600A has a higher degree of Quality ofService (QoS) as compared to the second session of 605A (e.g., which mayhave no QoS at all).

Further assume, at this point, that AT 1 is positioned in a relatively‘fast’ network that is capable of supporting AT 1's real-time mediatransmissions for the first session (i.e., the streaming communicationsession) and is also capable of concurrently supporting AT 1's packettransmissions at a given payload-size for the second session (i.e., thefile-transfer session).

Accordingly, AT 1 transmits streaming packet #1 for the first session,610A, and AT 1 then transmits data packet #1 for the second session,615A and 616A. AT 1 then transmits streaming packet #2 for the firstsession, 620A, and AT 1 then transmits data packet #2 for the secondsession, 625A and 626A. AT 1 then transmits streaming packet #3 for thefirst session, 630A.

Below, references are made to a ‘lower’ data-rate environment and a‘higher’ data-rate environment. As will be appreciated, based on thetype of data being transferred (and how much data is beingsimultaneously or concurrently transferred), there is some expectationof time for the user to have a ‘good’ user experience. In this case, anominal data rate can be determined whereby most users would be expectedto consider their experience-level to be satisfactory. The nominaldata-rate can vary between different network technologies (e.g., EV-DO,LTE, WiFi, etc.) and also can even vary based on individualuser-performance expectations and/or other factors. Accordingly, as usedherein, a lower data-rate environment is associated with a lowerexpected or actual data-rate as compared to a higher data-rateenvironment. Also, as used herein, the lower-data rate environment isassociated with an actual or expected data rate that is lower than therelevant nominal data-rate, and the higher-data rate environment isassociated with an actual or expected data rate that is greater than orequal to the relevant nominal data-rate.

At this point, assume that AT 1 transitions to a lower data-rateenvironment (e.g., via a handoff from an EV-DO to a 1x system, due to adeterioration in network conditions without a handoff to anothernetwork, due to the same physical-channel resources being shared bymultiple sessions or applications, etc.), 635A. Accordingly, AT 1 stillsends data packet #3 for the second session as scheduled, 640A, and theapplication server 170 sends data packet #3 to AT 2, 641A. However, dueto the lower data-rate environment, the transmission of data packet #3takes a longer amount of time and overlaps, in part, with the slotduring which streaming packet #4 for the first session. Accordingly,streaming packet #4 for the first session is dropped or delayed in 645Aduring its scheduled slot so that data packet #3 for the second sessioncan complete its transmission. Streaming packet #4 for the first sessionis then re-scheduled for transmission for a slot after the transmissionof data packet #3 for the second session in 650A.

As will be appreciated, in FIG. 6A, even though the first session isgenerally more susceptible delays in packet-transmission, the lowerdata-rate environment causes the transmission of data packet #3 to delaythe transmission of the next streaming packet for the first session. Forexample, because functional layer 1 already has a certain number ofpackets in its transmission queue, it can be difficult to maintainpackets of the first session prioritized over packets of the secondsession begin the second session's packets are already in the queue.

Accordingly, FIG. 6B illustrates an embodiment of the invention wherebythe size of data packets for non-streaming sessions, such asfile-transfer sessions, are dynamically modified such that delays topacket transmissions of real-time or streaming sessions are reducedand/or avoided entirely. Referring to FIG. 6B, 600B through 630Bsubstantially correspond to 600A through 630A of FIG. 6A, respectively,and as such will not be described further for the sake of brevity.

In 635B, AT 1 detects that it has transitioned to a lower data-rateenvironment (e.g., in 635A, AT 1 does not necessarily make thisdetection during the transition). In an example, the detection of thelower data-rate environment can correspond to entering a 1x, GeneralPacket Radio Service (GPRS), an Evolution-Data Optimized (EV-DO) Rel. 0Network or Rev. A network with QoS not available to the handset, etc.

After transitioning to a lower data-rate environment in 635B, AT 1dynamically reduces the size of the data payload within packets for thesecond session, 640B. For example, the payload-size reduction of 640Bcan be calculated based on a network to which AT 1 has transitioned(e.g., a first payload-size is used for file-transfer sessions overEV-DO networks, a second payload-size is used for file-transfer sessionsover 1x networks, etc.). Alternatively, the payload-size reduction of640B can be calculated based on any other type of estimation for thelower data-rate environment such that data packets of the second sessionwill not cause delays or rescheduling of the streaming data packets ofthe first session. Alternatively, the application server 170 cancalculate the size that can be allocated to the next data packet withoutincurring delays to the next streaming data packet, and the applicationserver 170 can convey the acceptable data-packet size to AT 1 (e.g., inan ACK packet, etc.).

Accordingly, AT 1 transmits data packet #3a for the second session, 645Band 646B. As noted above, the payload-portion of data packet #3a issmaller than the payload-portions of data packets #1 and/or #2 of 615Band 616B and/or 625B and 626B. Next, AT 1 transmits streaming packet #4for the first session, 650B. Unlike 645B and 646B, the streaming packet#4 for the first session can be sent on time and as a full-payloadpacket because packets for the second session instead of the firstsession are reduced in order to conform to AT 1's lower data-rateenvironment. The sessions continue whereby AT 1 transmits data packet#3b for the second session with the reduced payload-portion, 655B and656B, and then AT 1 transmits another streaming data packet #5, 660B,without rescheduling and at a full data-rate.

Accordingly, by prioritizing a streaming communication session over afile-transfer session, AT 1 can reduce the occurrence of rescheduling ordelaying real-time packets for the streaming communication session inthe event that AT 1 transitions to a lower data-rate environment.

Further, while FIG. 6B illustrates a particular example whereby AT 1transitions from a high data-rate environment or network to a lowdata-rate environment or network, it will be appreciated that FIG. 6B ismore broadly representative of a dynamic rate control algorithm (DRCA).For example, the DRCA can schedule high priority, delay-sensitivestreamed data at regular intervals (per the cadence of the application,as in the first session of FIG. 6B) and can transmit non-QoS data (e.g.,the second session in FIG. 6B) in a volume-regulated manner in the timeinterval between successive transmissions of the streamed data. Forexample, depending on the network type, the amount of data of thenon-QoS application can be limited to a fixed value.

Alternatively, the amount of data of the non-QoS application (i.e., thesecond session from FIG. 6B) can be adjusted in every successivetime-interval based on one adaptive or probing algorithms such asstarting with a conservative value, increasing the MTU size if thevoice/QoS packet is not impacted by the delay and reducing the amount ofdata transmitted if the voice packet is impacted by some delay. E.g.,learning algorithms such as reward-penalty algorithms can be used. Inanother alternative example, the amount of data of the non-QoSapplication (i.e., the second session from FIG. 6B) can be adjusted inevery successive time-interval based on precise information functionallayer 1 with regard to the number of slots required to transmit QoSstreaming data as well as past non-QoS streaming data, in which case theamount of data scheduled for the next time-interval can be calculated bythe handset (e.g., or the application server 170, which can then conveythis information to the handset or AT 1).

Thus, FIG. 6B explicitly shows data payload ‘reduction’ upon entry intoa lower data-rate environment. In an alternative example, FIG. 6B couldbe modified to accommodate an AT that transitions from the lowerdata-rate environment to a higher-data rate environment. In thisalternative example, the payload is increased upon entry into the higherdata-rate environment and many different mechanisms of computing theactual payload for the next non-QoS packet could be used. FIG. 6Cillustrates another conventional mechanism of supporting a file-transfersession concurrently with a streaming or real-time communicationsession. In particular, FIG. 6C is similar in some respects to FIG. 6A,except the target AT 2 transitions to the lower data-rate environmentinstead of the transmitting AT 1. Referring to FIG. 6C, 600C through630C substantially correspond to 600A through 630A of FIG. 6A,respectively, and/or 600B though 630B of FIG. 6B, respectively, and assuch will not be described further for the sake of brevity.

At this point, assume that AT 2 transitions to a lower data-rateenvironment (e.g., via a handoff from an EV-DO to a 1x system, due to adeterioration in network conditions without a handoff to anothernetwork, etc.), 635C. Accordingly, AT 1 still sends data packet #3 forthe second session as scheduled, 640C, and the application server 170begins the transmission of data packet #3 to AT 2, 641C. Before datapacket #3 completes its transmission to AT 2, AT 1 sends streamingpacket #4 for the first session to the application server 170 fortransmission to AT 2. The application server 170 delays the forwardingof the streaming packet #4 to AT 2, 646C. In other words, due to thelower data-rate environment of AT 2, the transmission of data packet #3from the application server 170 to AT 2 takes a longer amount of timeand overlaps, in part, with the slot during which streaming packet #4for the first session is scheduled. Accordingly, streaming packet #4 forthe first session is delayed in 646C. Streaming packet #4 for the firstsession is then re-scheduled for transmission for a slot after thetransmission of data packet #3 for the second session in 647C.

As will be appreciated, in FIG. 6C, even though the first session isgenerally more susceptible to delays in packet-transmission, the lowerdata-rate environment causes the transmission of data packet #3 to delaythe transmission of the next streaming packet for the first session.

Accordingly, FIG. 6D illustrates an embodiment of the invention wherebythe size of data packets for downlink non-streaming sessions, such asfile-transfer sessions, are dynamically modified at the applicationserver 170 and/or the RAN 120 such that delays to packet transmissionsof real-time or streaming sessions are reduced and/or avoided entirely.Referring to FIG. 6D, 600D through 635D substantially correspond to 600Cthrough 635C of FIG. 6C, respectively, and as such will not be describedfurther for the sake of brevity.

Referring to FIG. 6D, after AT 2 transitions to the lower data-rateenvironment in 635D, the application server 170 detects AT 2'stransition to the lower data-rate environment, 640D. For example, thedetection at the application server 170 of AT 2's transition to thelower data-rate environment can correspond to (i) a notification from AT2 or the RAN 120 regarding AT 2's current data-rate environment, (ii) adetection of performance degradation of the application server 170'sconnection to AT 2, (iii) a report of AT 2's current location, where theapplication server 170 has knowledge of data-rates associated withparticular geographic regions or serving areas, and/or (iv) any othermechanism by which the application server 170 can infer performancecharacteristics of its link or connection to AT 2.

Upon determining that AT 2 has transitioned to a lower data-rateenvironment in 640D, the application server 170 reduces the payload ofthe individual data packets that the application server 170 isforwarding to AT 2 for the second session, 645D. For example, thepayload-size reduction of 645D can be calculated based on a network towhich AT 2 has transitioned (e.g., a first payload-size is used forfile-transfer sessions over EV-DO networks, a second payload-size isused for file-transfer sessions over 1x networks, etc.). Alternatively,the payload-size reduction of 645D can be calculated based on any othertype of estimation for the lower data-rate environment such that datapackets of the second session will not cause delays or rescheduling ofthe streaming data packets of the first session. Alternatively, AT 2 cancalculate the size that can be allocated to the next data packet withoutincurring delays to the next streaming data packet, and AT 2 can conveythe acceptable data-packet size to the application server 170 (e.g., inan ACK packet, etc.).

Accordingly, AT 1 transmits data packet #3 for the second session with anormal or full-sized payload portion, 650D. Upon receiving data packet#3 from AT 1, the application server 170 reduces the payload-size ofdata packet #3 to generate data packet #3a having a reducedpayload-portion, while buffering any data-payload that was excluded fromdata packet #3a. The application server 170 then sends data packet #3ato AT 2, 651D. Next, AT 1 transmits streaming packet #4 for the firstsession to the application server 170, 655D, and the application server170 is able to send the streaming packet #4 to AT 2 without incurringthe delays shown in FIG. 6C because the RAN 120 is able to transmit datapacket #3a more quickly due to its decreased payload size, 656D. In660D, the application server 170 transmits data packet #3b for thesecond session with the reduced payload-portion.

Accordingly, by prioritizing a streaming communication session over afile-transfer session, the application server 170 can reduce theoccurrence of rescheduling or delaying real-time packets for thestreaming communication session in the event that the target AT 2transitions to a lower data-rate environment.

Further, while FIG. 6D illustrates a particular example whereby AT 2transitions from a high data-rate environment or network to a lowdata-rate environment or network, it will be appreciated that FIG. 6D ismore broadly representative of a dynamic rate control algorithm (DRCA).For example, the DRCA can schedule high priority, delay-sensitivestreamed data at regular intervals (per the cadence of the application,as in the first session of FIG. 6D) and can transmit non-QoS data (e.g.,the second session in FIG. 6D) in a volume-regulated manner in the timeinterval between successive transmissions of the streamed data. Forexample, depending on the network type, the amount of data of thenon-QoS application can be limited to a fixed value.

Alternatively, the amount of data of the non-QoS application (i.e., thesecond session from FIG. 6D) can be adjusted in every successivetime-interval based on one adaptive or probing algorithms such asstarting with a conservative value, increasing the MTU size if thevoice/QoS packet is not impacted by the delay and reducing the amount ofdata transmitted if the voice packet is impacted by some delay. Forexample, learning algorithms such as reward-penalty algorithms can beused. In another alternative example, the amount of data of the non-QoSapplication (i.e., the second session from FIG. 6D) can be adjusted inevery successive time-interval based on precise information with regardto the number of slots required to transmit QoS streaming data as wellas past non-QoS streaming data, in which case the amount of datascheduled for the next time-interval can be calculated by theapplication server 170 (e.g., or the handset, which can then convey thisinformation to the application server 170). Thus, while FIG. 6Dexplicitly shows data payload ‘reduction’ upon entry into a lowerdata-rate environment, the manner in which the data payload is adjustedin other embodiments could increase the payload (e.g., upon entry into ahigher data-rate environment) and many different mechanisms of computingthe actual payload for the next non-QoS packet could be used.

Also, while FIG. 6D illustrates the application server 170 performingthe dynamic payload reduction for the non-QoS or non-real-time session,it will be appreciated that these operations can be performed by AT 2'sRAN 120 in other embodiments of the invention. In this case, theapplication server 170 would forward the data packets for the first andsecond sessions to the RAN 120, where the RAN 120 would be responsiblefor dynamically reducing the payload size of the streaming packets toensure that the transmission of the non-streaming packets does not incurdelays to the streaming session.

FIG. 7A illustrates a conventional mechanism of supporting afile-transfer session concurrently with a streaming or real-timecommunication session. Accordingly, referring to FIG. 7A, assume thatthe application server 170 sets up a first session corresponding to astreaming voice communication session (e.g., a VoIP session) between AT1 and AT 2, 700A, and that the application server 170 then sets-up asecond session corresponding to a file-transfer session to facilitatethe transfer of one or more files from AT 1 to AT 2, 705A. It may befurther assumed that the first session of 700A has a higher degree ofQuality of Service (QoS) as compared to the second session of 705A(e.g., which may have no QoS at all). In particular, FIG. 7A isdescribed whereby a user of AT 1 is transferring the spoken question“Hello, how are you doing today?” to AT 2 and a user of AT 2 responds tothe user of AT 1's question by indicating “Good.”. During this verbalexchange of the first session, assume that AT 1 is also sending datapackets for the second session to AT 2.

Accordingly, AT 1 voice packet #1 (“Hello, How”) for the first session,710A, and AT 1 then transmits data packet #1 for the second session,715A and 716A. AT 1 then transmits voice packet #2 (“Are You”) for thefirst session, 720A, and AT 1 then transmits data packet #2 for thesecond session, 725A and 726A. AT 1 then transmits voice packet #3(“Doing Today?”) for the first session, 730A, and AT 1 then transmitsdata packet #3 for the second session, 735A and 736A.

At this point, assume that a user of AT 1 stops talking into amicrophone of AT 1. As such, AT 1 transmits a silence packet as voicepacket #4, where a silence packet corresponds to a voice packet thatonly includes silence frames, 740A. Silence packets include a relativelysmall data payload and generally contain only background ‘comfort’noise, but are treated on the network with the same QoS as a ‘real’voice packet. As will be appreciated, in the concurrent voice and mediacontext, these silence packets are packets where data for thefile-transfer session or second session could have been sent instead.Thereafter, AT 1 sends data packet #4 for the second session, 745A and746A, and eventually AT 2 responds to AT 1's question by responding withits own voice response packet #1 (“Good.”), 750A.

As will be appreciated, in FIG. 7A, AT 1 sends its silence packet eventhough little to no actual voice-data is contained therein. Accordingly,for concurrent sessions where a file-transfer is taking place at thesame time that a voice (or other multimedia) session is taking place,silence packets can be suppressed and data packets for the file-transfersession can be sent in their place, as will be described next withrespect to FIG. 7B.

Accordingly, FIG. 7B illustrates an embodiment of the invention wherebysilence frames for a streaming multimedia session are suppressed and anincreased number of data packets for a low-QoS or non-QoS file-transfersession are transmitted. Referring to FIG. 7B, 700B through 736Bsubstantially correspond to 700A through 736A of FIG. 7A, respectively,and as such will not be described further for the sake of brevity.

After transmitting data packet #3 for the second session in 735B, AT 1determines that the next queued streaming voice packet corresponds to asilence packet, 740B. As used herein, a silence packet can correspond toa series of silence frames. For example, if a series of silence framesamounting to a threshold time period (e.g., 100 ms) of silence isdetected in 740B, this may constitute detection of a silence packet,because a next voice packet (e.g., RTP packet) will only include silenceframes and will not include actual voice data (i.e., noise). In anexample, EV-DO protocols specify 20 ms per silence frames, in which caseAT 1 can count the number of 20 ms frames to be included in the nextvoice packet, and if each of these 20 ms frames are silence frames, AT 1determines that the next voice packet is a silence packet.

Further, silence frames can be relatively easy to detect because eachsilence frame is generally constructed in a standard fashion.Accordingly, AT 1 can compare each voice frame with a predeterminedsilence frame. By storing a single silence frame to use as a template,AT 1 can compare the template silence frame with its queuedvoice-packets to determine whether a particular voice-packet is carryinga silence frame.

After determining that the next queued streaming voice packetcorresponds to a silence packet in 740B, AT 1 suppresses thesilence-packet and schedules the next queued data-packet for the secondsession in the slot that was to carry the silence packet or voice packet#4, 745B. AT 1 then transmits the next queued data-packet (i.e., datapacket #4) for the second session in the slot that was initiallyscheduled for voice packet #4 of the first session, 750B. AT 2 receivesthe unexpected data packet #4 in 751B and interprets the consecutivereceipt of non-streaming or non-voice data packets for the secondsession as an indication that AT 1 suppressed a silence packet for thefirst session, and thereby plays ‘comfort’ noise as AT 2 would have ifAT 1 had actually transmitted the silence packet including the series ofsilence frames, 755B.

AT 1 then transmits data packet #5 for the second session in the slotinitially scheduled for transmission of data packet #4 before datapacket #4 replaced the silence packet, 760B. At some later point intime, AT 2 responds to AT 1's question by responding with its own voiceresponse packet #1 (“Good.”), 765B. Accordingly, by suppressing silencepackets when a streaming communication session is conducted concurrentlywith a file-transfer session, data packets for the file-transfersession, which typically have a lower-priority than voice packets of thestreaming session, are sent in their place.

FIG. 7C illustrates another embodiment of the invention whereby silenceframes for a streaming multimedia session are suppressed and anincreased number of data packets for a low-QoS or non-QoS file-transfersession are transmitted. In particular, FIG. 7C is similar in somerespects to FIG. 7B, except the silence-packet suppression occurs at theapplication server 170 instead of the transmitting AT 1. Referring toFIG. 7C, 700C through 736C substantially correspond to 700A through 736Aof FIG. 7A, respectively, and/or 700B through 736B of FIG. 7B,respectively, and as such will not be described further for the sake ofbrevity.

Referring to FIG. 7C, after transmitting data packet #3 for the secondsession in 735C and 736C, AT 1 transmits voice packet #4 to theapplication server 170 for the first session, 740C. In the embodiment ofFIG. 7C, it may be assumed that voice packet #4 corresponds to a silencepacket that includes a given number of silence frames. The applicationserver 170 receives and evaluates voice packet #4 and determines thatvoice packet #4 is a silence packet, 745C. After determining that thenext streaming voice packet #4 corresponds to a silence packet in 745C,the application server 170 suppresses the silence-packet and determinesto schedule the next packet received from AT 1 for AT 2 (e.g., either adata packet for the second session or non-silence packet for the firstsession) instead of sending voice packet #4, 750C.

Accordingly, AT 1 then transmits the next queued data-packet (i.e., datapacket #4) for the second session to the application server 170, 755C.In this example, data packet #4 is sent in its scheduled slot with nochange at AT 1. The application server 170 receives data packet #4 andforwards data packet #4 to AT 2 in the slot that was initially scheduledfor voice packet #4 of the first session, 756C. AT 2 receives theunexpected data packet #4 and interprets the consecutive receipt ofnon-streaming or non-voice data packets for the second session as anindication that the application server 170 suppressed a silence packetfor the first session, and thereby plays ‘comfort’ noise as AT 2 wouldhave if AT 1 had actually transmitted the silence packet including theseries of silence frames, 760C.

At some later point in time, AT 2 responds to AT 1's question byresponding with its own voice response packet #1 (“Good.”), 765C.Accordingly, by suppressing silence packets when a streamingcommunication session is conducted concurrently with a file-transfersession, data packets for the file-transfer session, which typicallyhave a lower-priority than voice packets of the streaming session, aresent in their place by the application server 170.

FIG. 8A illustrates a process that focuses on the end or completion of aconventional file-transfer session. Referring to FIG. 8A, theapplication server 170 sets-up a file-transfer session to facilitate thetransfer of one or more files from AT 1 to AT 2, 800A. In the example ofFIG. 8A, it may be assumed that the file-transfer session corresponds toa transfer of a plurality of data packets 1 . . . N, where N>=3.Accordingly, after the file-transfer session is set-up in 800A, AT 1sends data packets 1 . . . N−2 for the file-transfer session to AT 2,805A and 806A. The application server 170 ACKs data packets 1 . . . N−2in 809A. Assume that AT 2 receives each of data packets 1 . . . N−2, andthereby AT 2 also sends ACKs for each of data packets 1 . . . N−2 backto the application server 170, 810A. Next, AT 1 sends data packet N−1and N, which are the last two packets for the file-transfer session,815A and 816A, and 820A and 821A.

At this time, because AT 1 has transmitted all of its packets for thefile-transfer session to AT 2, AT 1 stops transmitting data in 825A.However, also in 825A, because AT 1 has not yet received ACKs to all ofits transmitted data packets (i.e., data packets N−1 and N), AT 1retains its TCH because there is a possibility a NACK will be receivedfor data packet N−1 and/or data packet N (or an ACK-timeout), in whichcase a packet retransmission will be required. The application server170 ACKs data packets N−1 and N in 829A, after which AT 1 tears down theTCH, 830A. In this example, assume that AT 2 eventually also sends ACKsfor both data packets N−1 and N, 835A.

As will be appreciated, in the event that data packets N−1 and N areACKed as shown in FIG. 8A, AT 1 unnecessarily holds onto its TCH forlonger than is actually necessary for the file-transfer session. Also,in the event that a retransmission of data packets N−1 and/or N isrequired, the period from the initial transmission of these data packetsto their eventual retransmission corresponds to ‘wasted’ time duringwhich AT 1 has a TCH but is not actually transmitting data, as will bedescribed next with respect to FIG. 8B. FIG. 8B another conventionalprocess focuses on the signaling between AT 1 and the application server170 at the end of a file-transfer session, and as such signaling betweenAT 2 and the application server 170 is shown via a dotted line.

Referring to FIG. 8B, 800B through 810B substantially correspond to 800Athrough 810A of FIG. 8A, respectively, and as such will not be describedfurther for the sake of brevity. After receiving ACKs for data packets 1. . . N−2, AT 1 attempts to transmit data packet N−1, 820B, and datapacket N, 825B (e.g., although some of the ACKs from 815B could actuallybe received after one or more of these transmission attempts). In theembodiment of FIG. 8B, assume that the transmission attempts of bothdata packet N−1 and N fail in 820B and 825B, respectively.

In 830B, as in 825A of FIG. 8A, AT 1 stops transmitting data and retainsits TCH. Next, the application server 170 sends NACKs for data packetsN−1 and N to AT 1, 837B. Also, after a given period of time, AT 2 alsodetermines to send NACKs for data packets N−1 and N to the applicationserver 170, 839B, and the NACKs are sent from AT 2 to the applicationserver 170 in 838B. Accordingly, AT 1 re-transmits data packets N−1 andN in 840B and 841B, and 845B and 846B, respectively. The applicationserver 170 ACKs data packets N−1 and N from AT 1, 849B, after which AT 1can tear down the TCH, 850B. AT 2 also ACKs data packets N−1 and N thatare successfully received at AT 2 from the application server 170, 855B.

As will now be described with respect to FIGS. 8C and 8D, embodiments ofthe invention are directed to an opportunistic or preemptivere-transmission of data packets during periods where a transmitting AThas a TCH and is not transmitting data. FIGS. 8C and 8D, similar to FIG.8B, each focus on the signaling between AT 1 and the application server170, and as such signaling between AT 2 and the application server 170is shown via a dotted line.

Referring to FIG. 8C, 800C through 821C substantially correspond to 800Athrough 821A of FIG. 8A, respectively, and as such will not be describedfurther for the sake of brevity. After transmitting data packets N−1 andN in 815C and 816C, respectively, instead of simply holding onto the TCHand waiting for an ACK or a NACK from AT 2, AT 1 maintains its TCH anddetermines to preemptively re-transmit data packets N−1 and N beforeACKs or NACKs to these data packets are actually received, 825C.

Accordingly, AT 1 re-transmits data packets N−1 and N to the applicationserver 170 in 830C and 835C, and the application server 170 forwardsdata packets N−1 and N to AT 2 in 831C and 836C, respectively. Theapplication server 170 ACKs data packets N−1 and N, 837C, after which AT1 can tear down the TCH, 840C. Also, AT 2 ACKs data packets N−1 and N tothe application server 170, 845C. It will be appreciated that the ACKsreceived in 837C at AT 1 can be either for the initial transmission ofdata packets N−1 and N in 815C through 820C, or for the re-transmissionof data packets N−1 and N in 830C through 835C (or some combination,where at least one ACK is for an initial transmission and at least oneACK is for a re-transmission).

Further, while FIG. 8C shows a single re-transmission of data packetsN−1 and N, it will be appreciated that AT 1 can simply continue tore-transmit data packets N−1 and N until an ACK or NACK is received fromthe application server 170, or for a given number of times (e.g., threeretransmissions, etc.). Further, while FIG. 8C is directed to an examplewhere re-transmissions are performed for the last two data packets in astream of data packets for a file-transfer session (i.e., data packetsN−1 and N), other embodiments can perform the above-described preemptivepacket retransmission(s) for different numbers of packets, such as thelast three packets, the last four packets, only the last packet, etc.

Referring to FIG. 8D, 800D through 825D substantially correspond to 800Bthrough 825B of FIG. 8B, respectively, and as such will not be describedfurther for the sake of brevity. After unsuccessfully attempting totransmit data packets N−1 and N in 820D and 825D, respectively, insteadof simply holding onto the TCH and waiting for an ACK-timeout or a ACKor a NACK from the application server 170, AT 1 maintains its TCH anddetermines to preemptively re-transmit data packets N−1 and N beforeACKs or NACKs, 830D.

Accordingly, AT 1 re-transmits data packets N−1 and N to the applicationserver 170 in 831D and 836D, and the application server 170 forwardsdata packets N−1 and N to AT 2 in 836D and 841D, respectively. At somelater point in time, assume that AT 1 receives ACKs for data packets N−1and N from the application server 170, 845D (e.g., in an example, NACKsto earlier transmissions of data packets N−1 and N from 831D and 835Dmay also be received at AT 1, but it is assumed in this case that one ofthe retransmissions is successfully sent to the application server 170).It will be appreciated that the ACKs received in 845D at AT 1 are forthe re-transmission of data packets N−1 and N in 831D and 835D (e.g.,because the initial transmissions of these data packets is assumed to beunsuccessful). At this point, AT 1 can tear down the TCH, 850D. At somelater point in time, AT 2 can also ACK its receipt of data packets N−1and N to the application server 170, 855D.

Further, while FIG. 8D shows a single re-transmission of data packetsN−1 and N, it will be appreciated that AT 1 can simply continue tore-transmit data packets N−1 and N until an ACK-timeout is determined oran ACK or NACK is received from the application server 170, or for agiven number of times (e.g., three retransmissions, etc.). Further,while FIG. 8D is directed to an example where re-transmissions areperformed for the last two data packets in a stream of data packets fora file-transfer session (i.e., data packets N−1 and N), otherembodiments can perform the above-described preemptive packetretransmission(s) for different numbers of packets, such as the lastthree packets, the last four packets, only the last packet, etc.

Further, while FIGS. 8C and 8D each show examples by which a preemptivere-transmission of data packets occurs near the expected end-point of afile-transfer session, it will be appreciated that other conditionscould be used to trigger a preemptive re-transmission of packets where aTCH is maintained by an AT and is not used continuously. For example,the sender could be measuring the exact network conditions and, if thenetwork conditions are determine to be poor and it is more likely thatthere is loss, then the sender can optimistically retransmit the lastwindow of packets. Alternatively, the sender (i.e., AT 1) could employ agiven type of ‘learning’ algorithm that measures how many packets werelost over the course of the connection (available from ACK andretransmits) and makes an educated guess as to when to performpreemptive retransmissions. The learning algorithm could be even morecomplicated and extend to the life of particular calls to particulartargets, location, time of the day, etc. In an example, not only couldthe learning algorithm predict when to preemptively retransmit datapackets, but the learning algorithm could also predict the order orwhich packets to retransmit based on the likelihood of loss.

FIG. 8E is directed to another an opportunistic or preemptivere-transmission of data packets during periods where a transmitting AThas a TCH and is not transmitting data in accordance with an embodimentof the invention. Unlike FIGS. 8C and 8D, FIG. 8E is directed to animplementation whereby the opportunistic or preemptive re-transmissionis triggered or originated from the application server 170 instead ofthe transmitting AT 1. Accordingly, FIG. 8E focuses on the signalingbetween AT 2 and the application server 170, and as such signalingbetween AT 1 and the application server 170 is shown via a dotted line.

Referring to FIG. 8E, 800E through 810E substantially correspond to 800Dthrough 810D of FIG. 8D, respectively, and as such will not be describedfurther for the sake of brevity. Unlike FIG. 8C, in 815 and 820E, AT 1successfully sends data packets N−1 and N to the application server 170.However, the application server 170 is unable to successfully transmitdata packets N−1 and N to AT 2 in 816E and 821E, respectively.

The application server 170 ACKs data packets N−1 and N in 825E, afterwhich AT 1 can tear down its TCH, 826E. In 830E, instead of simplyforwarding one instance of data packets N−1 and N, the applicationserver 170 determines to preemptively re-transmit data packets N−1 and Nbefore ACKs or NACKs to these data packets are actually received from AT2. In an example, the determination of 830E can be based on theapplication server 170's knowledge that data packets N−1 and Ncorrespond to the last two packets for the communication session, in anexample.

Accordingly, the application server 170 re-transmits data packets N−1and N to AT 2 in 835E and 840E, respectively. At some later point intime, assume that the application server 170 receives ACKs for datapackets N−1 and N from AT 2, 845E. At this point, the application server170 can stop its re-transmission of data packets N−1 and N (if theapplication server 170 has not done so already), 850E.

Further, while FIG. 8E shows a single re-transmission of data packetsN−1 and N, it will be appreciated that the application server 170 cansimply continue to re-transmit data packets N−1 and N until an ACK orNACK is received from AT 2, or for a given number of times (e.g., threeretransmissions, etc.). Further, while FIG. 8E is directed to an examplewhere re-transmissions are performed for the last two data packets in astream of data packets for a file-transfer session (i.e., data packetsN−1 and N), other embodiments can perform the above-described preemptivepacket retransmission(s) for different numbers of packets, such as thelast three packets, the last four packets, only the last packet, etc.

Embodiments of content-based processes will now be described withrespect to FIGS. 9A through 9D. As used herein, in the context of adisplay on an AT, a window corresponds to object(s) configured to beviewable on the display and is associated with a particular applicationexecuting on the AT. For example, assume that the AT corresponds to acellular telephone, the AT is executing a mobile web browsingapplication and a particular web-page is being displayed to the user onthe display. In this case, the window corresponds to a graphicalconstruct used by the mobile web browsing application to present theparticular web-page to the AT's user on the display. While windows asused herein are configured to be viewable on the display of the AT, itwill be appreciated that each window need not be viewable on the displayof the AT at all times. For example, a particular window that wouldotherwise be viewable on the display of the AT may be minimized oroverlapped by another window and thereby, for a period of time, wouldnot be viewable on the display of the AT.

In another example, different windows on a display of an AT can beassociated with different objects that a user of the AT has requestedfor download. In the case of the mobile web browsing application, thedifferent objects can include a set of objects to be displayed and/orpresented to the AT's user in association with the particular web pageof the window. However, less than all of these windows may be ‘active’at a given time. For example, a given user of the AT can request thatfour (4) different websites be loaded on the AT via the mobile webbrowsing application, but the given user can set one of the fourwebsites to an ‘active’ or viewable status on the AT. Alternatively,multiple windows can be viewable but one particular window is presentedmore prominently than the others (i.e., the ‘active’ window, such aswhen the active window is completely viewable on the display of the ATand other windows are partially and/or fully overlapped by or covered upby the active window). As will be appreciated, this suggests that theuser is interested in viewing the active website before the otherwebsites. However, the server from which the objects of the fourwebsites are downloaded conventionally is unaware of which window thegiven user has established as active. Accordingly, FIG. 9A illustrates aprocess of selectively downloading file objects to an AT in accordancewith a content-based priority scheme in an embodiment of the invention.

Referring to FIG. 9A, a given AT (“AT 2”) receives one or more userrequests to download multiple objects, 900A. In an example, therequest(s) of 900A can correspond to a user of AT 2 requesting thedownload, or a message received from AT 1 that indicates a user of AT 1is requesting to send the multiple objects to AT 2, or a combinationthereof. As noted above, the request of 900A could correspond to arequest to load content associated with different websites in multiplewindows of a web-browser. In 905A, AT 2 determines which window on AT 2is currently ‘active’. As noted above, an ‘active’ window can correspondto which browser window (or windows) is most prominently on AT 2, asopposed to ‘hidden’ windows that are not currently selected by a user ofAT 2. Next, AT 2 determines at least one of the multiple objects from900A to be associated with the current active window, 910A. For example,if the user requests in 900A to load a sports web-site and also to loada news-website, and a window in which the sports web-site is to bedisplayed is most prominently displayed on AT 2, then the files orobjects determined to be associated with the current active window in910A are the objects associated with the sports web-site.

In 915A, AT 2 configures one or more download requests to request adownload of the multiple objects from the application server 170, andfurther configures the request(s) to indicate which objects areassociated with the current active window of AT 2, 915A. As will beappreciated, the indication of which objects are associated with thecurrent active window of AT functions to prioritize the associatedobjects over the non-associated objects. In 920A, AT 2 sends theconfigured request(s) to the application server 170, 920A. Theapplication server 170 then forwards the configured request to AT 1,922A. Responsive to the configured request(s) received in 920A, AT 1begins sending the multiple objects to AT 2 in accordance with theobject priorities indicated in the configured request(s) that wasforwarded to AT 1 in 922A, 924A. For example, AT 1 can provide objectsthat are associated with AT 2's current active window first, followed bynon-associated objects. Likewise, the application server 170 receivesthe objects from AT 1 in 924A, and then begins to provide the multipleobjects to AT 2 in accordance with the object priorities of theconfigured request(s), 925A.

During the download of the multiple objects, AT 2 determines whether itscurrent active window has changed, 930A. If not, AT 2 determines whetherthe download is complete, 933A. If the download completes, the processreturns to 900A where AT 2 waits for a next object download request.Otherwise, if the current active window has not changed and the downloadis not yet complete, AT 2 continues to monitor the download of themultiple objects. However, if AT 2 determines its current active windowhas changed in 930A (e.g., if a user transitions AT 2 to a differentactive window), then AT 2 determines at least one of the multipleobjects from 900A to be associated with its new current active window,935A.

In 940A, AT 1 configures one or more supplemental download requests torequest a download of the multiple objects from the application server170, and further configures the supplemental request(s) to indicatewhich objects are associated with AT 2's new current active window. In945A, AT 2 sends the configured supplemental request(s) to theapplication server 170. Responsive to the configured supplementalrequest(s) received in 945A, the application server 170 updates thedownload priority for providing the multiple objects to AT 2 from theapplication server 170 and also updates the upload priority by which AT1 uploads the multiple objects to the application server 170 (e.g., atleast for 1-to-1 communication sessions between AT 1 and AT 2 only),950A. Also in 950A, the application server 170 can send a message to AT1 that requests AT 1 modify its upload order to conform with the new orupdated object priorities based on AT 2's window-change. In an example,the upload and download orders or priorities can be set to be the same.For example, for files A, B, C and D, the download order may be[A,B,C,D] and the upload order may also be [A,B,C,D]. In an alternativeembodiment, however, the upload and download orders need not be thesame. For example, the download order may be [A,B,C,D] and the uploadorder may be [A,C,D] if file B is already accessible at the applicationserver 170.

Thereafter, the AT 1 continues to send the multiple objects to theapplication server 170 in accordance with the object prioritiesindicated in the configured supplemental request(s), and the applicationserver 170 likewise continues to send the multiple objects to AT 2 inaccordance with the object priorities indicated in the configuredsupplemental request(s).

As will be appreciated, FIG. 9A describes a process by which a user'scontent priorities are inferred based on which window the user has setto be active, and the inferred user-priority is then conveyed to thedownload server (or application server 170). In another example, theuser can explicitly establish its priorities for downloading objects,such that inferring a user's expected priorities from the behavior ofthe user need not be performed.

As such, referring to FIG. 9B, AT 2 receives a set of user-specifiedobject download priorities, 900B. The set of user-specified objectdownload priorities could be configured in a number of different ways.

For example, the set of user-specified object download priorities couldbe configured to prioritize certain mime types over other mime types(e.g., to prioritize text over graphical images, to prioritize videoover audio, to prioritize audio over graphics, etc.). For example, AT 2can track a frequency at which objects with a plurality of differentmime types have been downloaded historically, and can then allocate ahigher priority to more-frequently downloaded mime types. In anotherexample, a z-index of different layers using cascading style sheets(CSS) can be generated, as is popular with many websites, whereby thez-index can convey the priority within a given page. Thus, if aparticular website is a music-related website, audio may be prioritizedover other forms of media (e.g., text, images, video, etc.). In anotherexample, if a particular website is related to graphic still images orart, then images may be prioritized over other forms of media (e.g.,text, audio, etc.). In a further example, the z-indices of differentwebsites may be used to establish priorities between the websites, suchthat if AT 2 is attempting to load multiple websites at the same timethe objects of the respective websites can be downloaded in accordancewith their relative priority levels. In another example, a webpage thatincludes CSS elements (e.g., a background template, navigation bars,body text, and/or other javascript widgets) could organize the z-indexin a particular order (e.g., body text, navigation bars, backgroundtemplate, and javascript widgets, in order) to enhance the userexperience.

In another embodiment, the set of user-specified object downloadpriorities could be to prioritize files for certain applications overother applications. In an example, the type of application may beindicative of its importance or urgency, such that the more important ormore urgent application is given priority, such that a web-browsingsession is prioritized over a passive OS update, for example. In anotherexample, AT 2 may track information related to how frequentlyapplications are used or executed. The historical usage information forthe applications can then be used to establish relative priorities amongthe applications, such that more frequency used applications areprioritized over less frequency used applications.

In another example, each time a user of AT 2 requests a file download(e.g., each time a user navigates and clicks on a URL, etc.), a timestamp associated with the file download request can be stored at AT 2.The relative times at which the user of AT 2 requests respective filedownloads can then be used to establish relative priorities between thefile downloads. For example, more recently initiated file downloadrequests can be prioritized over earlier or older file downloadrequests. At some later point in time, AT 2 receives one or more userrequests to download multiple objects, 905B. The request of 905B couldcorrespond to a request to load content associated with one or morewebsites, in an example, or to receive a file transfer from another ATduring a communication session. In 910B, AT 2 configures one or moredownload requests to request a download of the multiple objects from theapplication server 170, and further configures the request(s) toindicate which the set of user-specified object download priorities from900B. In 915B, AT 2 sends the configured request(s) to the applicationserver 170, 915B. The application server 170 then forwards theconfigured request to AT 1, 918B. Responsive to the configuredrequest(s), AT 1 begins sending the multiple objects to the applicationserver 170 in accordance with the set of user-specified object downloadpriorities indicated in the configured request(s), 920B, and theapplication server 170 likewise sends the multiple objects to AT 2 inaccordance with the object priorities indicated in the configuredrequest(s), 925B. As will be appreciated, from the perspective of AT 1,the object priorities can be construed as an upload priority instead ofa download priority. In any case, the order in which files are uploadedform AT 1 is maintained consistent with the order in which files aredownloaded to AT 2 from the application server 170.

In another embodiment, with respect to FIG. 9B, AT 2 may berepresentative of a plurality of ATs that are receiving objects from AT1. In this case, it will be appreciated that not all of the plurality ofATs may be permitted to affect the file-order in which AT 1 istransmitting the objects to the plurality of ATs. In an example, theapplication server 170 may forward the first-requested user-specifiedobject download priority from the plurality of ATs, and may thereafterdeny later-requested user-specified object download priorities. In analternative example, the application server 170 may forward alater-requested user-specified object download priority to AT 1, wherebyAT 1 will conform with a most-recently forwarded user-specified objectdownload priority, but only if the later-requested user-specified objectdownload priority is received at the application server 170 from ahigher-priority AT as compared to the first-requested orearlier-requested user-specified object download priority. In anotherexample, in the case that AT 2 is representative of a plurality of ATs,the application server 170 can performing a weighing or averaging ofdifferent requested user-specified object download priorities from therespective ATs. For example, the application server 170 may only actupon a particular set of user-specified object download priorities whena threshold number of percentage of ATs request the same set ofuser-specified object download priorities, the application server 170may determine common elements across multiple requested user-specifiedobject download priorities and then only act upon the common elements,and so on.

In another embodiment, with respect to FIG. 9B, AT 1 may berepresentative of a plurality of ATs that are transferring objects to AT2. In this case, the set of user-specified object download prioritiescan be configured to prioritize objects from certain ATs over other ATs.In this case, in an example, the configured requests for the multipleobjects in 915B can be queued by AT 2 and then be sent successively tothe plurality of ATs in order of highest-priority to lowest-priorityafter each AT completes its respective object transfer. Alternatively,AT 2 may notify the application server 170 of the ATs' respectivepriorities for AT 2. In this case, the configured requests for themultiple objects in 915B can be sent to each of the plurality of ATs,and the application server 170 can then attempt to buffer the objectsreceived from the plurality of ATs so as to deliver the objects to AT 2in an order corresponding to AT 2's set of user-specified objectdownload priorities.

In another example, as will be described next with respect to FIG. 9C, agiven user of AT 2 can navigate between windows that are associated withdifferent communication sessions (e.g., such as a streaming videoconference session and a file-transfer session). Depending on whichwindow is active, all or a portion of the media of the session that isnot associated with the active window can be de-prioritized (at leastuntil the given user navigates back to the window of the other session).For example, assume that, due to the layering of windows on AT 2, onlypartial video is displayed. In this case, only the portion of the windowthat is shown can be sent as part of the video. AT 2 can convey someindicator of the displayed video portion from which the applicationserver 170 can filter the non-viewable portion.

Referring to FIG. 9C, assume that AT 2 is participating in a streamingcommunication session associated with a first set of windows over afirst connection, 900C. In an example, the first connection (orconnection 1) can correspond to a single connection that carries asingle media type or multiple media types (e.g., video and audio). Inanother example, the first connection can correspond to a plurality ofdifferent connections with each type of streaming media being allocatedto a different one of the connections (e.g., audio is received over 1xand video is received over EV-DO, video and audio are received ondifferent ports within an EV-DO network, etc.). Also, the streamingcommunication session could be between AT 2 and a server, AT 1 or someother AT, and as such AT 1 is not explicitly illustrated as part of thestreaming communication session in FIG. 9C, although this is a possibleimplementation.

Next, AT 2 switches to a second set of windows in order to initiate afile-transfer session to transfer one or more objects over a secondconnection from a transmitting AT 1, 905C. For example, the streamingcommunication session can correspond to a video conference supported bya high QoS connection (i.e., the first connection), and thefile-transfer session can be supported by a low QoS connection or even aconnection that is not guaranteed any degree of QoS.

Because AT 2 has switched its current active window from a windowassociated with the streaming communication session to a windowassociated with the file-transfer session, AT 2 sends a request tode-prioritize at least a portion of the streaming communication sessionin 910C. In an example, if the streaming communication sessioncorresponds to a video-only session, the de-prioritization request canrequest that the video-feed no longer be sent to AT 2 because AT 2 isnot even watching the window that would display the video. In a furtherexample, if the streaming communication session corresponds to feedcontaining video and audio, the de-prioritization request can requestthat the video-feed no longer be sent to AT 1 while still requesting theaudio-feed or portion of the streaming communication session to be sentto AT 1 (e.g., because even though the video is not viewable in thisinstance, the user could still listen to the audio-portion of thesession during the user's navigation to the other window). In thisexample, if the first connection includes different connections foraudio and video, the de-prioritization request can be configured torequest that a rate at which the video frames are conveyed to AT 2 bereduced, or alternatively that the video connection be temporarilysuspended or shut-down. Accordingly, in 915C, the application server 170modifies the streaming communication session to AT 1 in accordance withthe de-prioritization request from 910C.

In 920C, AT 1 requests to download one or more objects over the secondconnection of the file-transfer session, and the application server 170forwards the download request to AT 1, 922C. AT 1 begins sending therequested objects to the application server 170, 924D, and theapplication server 170 sends the requested object(s) from AT 1 to AT 2over the second connection, 925C. In an example, AT 2 can download aphoto that is emailed to AT 2 from a session participant of thestreaming communication session (e.g., AT 1), such as a diagram that isbeing discussed. Alternatively, the file-transfer session need not bedirectly associated with the streaming communication session.

At this point, assume AT 2 switches back to the streaming communicationsession such that the first set of windows are again activated and AT 2can again fully participate in the streaming communication session,930C. Accordingly, AT 1 sends a ‘re’-prioritization request to requestthat the de-prioritized portion of the streaming communication sessionagain be given a high level of priority, 935C. For example, there-prioritization request can request that a discontinued video-feed ofa video-conference be resumed. Accordingly, in 940C, the applicationserver 170 modifies the streaming communication session to AT 1 inaccordance with the re-prioritization request from 935C.

In the embodiment of FIG. 9C, a given transport protocol (e.g., TCP,etc.) can be used to adjust the manner in which a particular set ofwindows is advertised to the application server 170 and/or AT 1 inassociation with a particular TCP connection. For example, a first TCPconnection can be associated with the first set of windows and a secondTCP connection can be associated with the second set of windows.Thereby, the de-prioritization request of 910C can correspond to aconfiguration of a smaller advertised window for the first TCPconnection of the first set of windows to reflect the lower-priority ofthe first set of windows, and the re-prioritization request of 935C cancorrespond to a configuration of a larger advertised window for thesecond TCP connection of the second set of windows to reflect thehigher-priority of the second set of windows. While the first and secondset of windows are described above as each being related to TCPconnections, it will be appreciated that, in other embodiments of theinvention, at least one of the connections need not be TCP, but couldrather be UDP or some other windowless transport protocol.

While FIGS. 9A through 9C illustrate examples by which the objects ormedia are selectively provided AT 2 based on either an inferred orexplicit priority of the content, it is generally assumed in FIGS. 9Athrough 9C that any data actually provided to AT 2 is conveyed at afull-quality level. In an alternative embodiment, described below withrespect to FIG. 9D, if AT 2 is positioned in a limited environment, AT 2can prompt a download of objects that are re-formatted to conform withthe limited environment.

As used herein, a ‘limited environment’ is defined as any condition,qualitative metric and/or quantitative metric that is expected to beassociated with performance degradation for a download request of AT 2.For example, the limited environment can correspond to as abandwidth-limited environment where AT 2 is operating in ahigh-interference zone, a 1x network and/or where AT 2's resources arestrained such as when AT 2 is concurrently participating in multiplesessions. In another example, AT 2 can be deemed to be in a limitedenvironment if AT 2 is connected to an EV-DO network and T2P of EV-DOfalls below a given threshold or a bandwidth measurement using CapProbeor CapProbe-like program falls beneath a predetermined threshold.

Referring to FIG. 9D, AT 2 receives at least one request to downloadmultiple objects, 900D. As noted above, the multiple-object downloadrequest can correspond to a request to load a website, in an example, orto receive a file transfer from another AT during a communicationsession. In another example, the multiple-object download request cancorrespond to a photo-slideshow. In 905D, AT 2 determines if AT 2 iscurrently operating in a limited environment that is expected to belimited relative to the download request.

As will be appreciated, there are a number of different manners by whichAT 2 can determine if its current operating environment is a ‘limitedenvironment’ (e.g., limited relative to the download request). Forexample, an environment can be limited relative to the download requestif the ratio of the amount of data requested to the time in which areasonable user expects to receive that amount of data would take longerthan a predetermined amount. This ratio can be preconfigured onrespective ATs or UEs, in an example. Thus, being connected to a 1xnetwork is not a limited environment if the AT is requested download ofa 10 kilobyte (KB) file, but the 1x network could be a limitedenvironment if the requested download is for a 10 megabyte (MB) file.Likewise, being connected to a 4 g network is not a limited environmentif the AT is requested download of a 10 MB file, but even the 4G networkcould be a limited environment if the requested download is for a 10gigabyte (GB) file.

In another example, if AT 2 is operating in a 1x network, AT 2 maysimply assume its environment is limited. In another example, AT 2 canevaluate a data-rate obtained in a recent communication session, and ifthe data-rate is relatively low or below a threshold then AT 2 candetermine its environment to be -limited.

In another example, the application server 170 (or the RAN 120) can senda connection quality indicator to AT 2 that indicates a level of AT 2'scurrent connection quality, as shown in 903D. For example, theconnection quality indicator can be indicative of network delay,congestion or loss associated with AT 2's current serving network asmeasured by the application server 170. As will be appreciated, asbandwidth increases and latency decreases, there will eventually be apoint at which there are diminishing returns in terms of user-experienceor user-perception, such that changes in bandwidth and/or latency can beevaluated to determine whether a particular operating environment islimited. In a further example, if AT 2 already has a connectionestablished with the application server 170, the connection qualityindicator can be conveyed to AT 2 within an ACK packet or data packetsent by the application server 170 to AT 2. For example, the applicationserver 170 may have special knowledge related to a connection quality ofAT 2's current network, which can be based on part on AT 2's geographiclocation for example. The application server 170 can then configure aheader portion (e.g., a DSCP field) of a packet to AT 2 with a code orbit-setting to convey the special knowledge.

It may be assumed in 905D that AT 2 determines its environment to be alimited environment. Accordingly, AT 2 configures one or more downloadrequests to request a download of the multiple objects from theapplication server 170, and further configures the request(s) toindicate that AT 2 is operating in a limited environment, 910D. In 915D,AT 2 sends the configured request(s) to the application server 170, andthe application server 170 forwards the configured request(s) to AT 1.Responsive to the configured request(s), AT 1 begins sending therequested objects via its own connection to the application server 170,920B. Upon receiving the multiple objects from AT 1, the applicationserver 170 alters or modifies at least one of the multiple-objects froma first ‘realization’ to a second ‘realization’ in order to reduce adelivery time of the at least one object to be altered or modified,922D. In an example, for a graphic object (e.g., a JPEG, TIFF, bitmap,etc.), the modification of 922D can correspond to a resolution reduction(e.g., normal-resolution to thumbnail image, etc.) of the graphic object(e.g., or for multiple graphic objects in the case of aphoto-slideshow). In another example, for an audio object (e.g., a wayfile, MP3, etc.) the modification of 922D can correspond to a qualityreduction of the audio object. After the modification of 922D, theapplication server 170 begins sending the multiple objects to AT 2 suchthat any modified objects are sent in place of their non-modifiedversions, 925D.

In 930D, at some later point in time, the application server 170determines whether to send the at least one object to AT 2 in theirfirst or non-modified format. In an example, the application server 170can determine to send the at least one object in its ‘full’ qualityfirst format after all other multiple objects are sent to AT 2, inresponse to a message that AT 2 is no longer operating in a limitedenvironment (e.g., via a connection quality update message in 928D, forinstance), after a threshold period of time, etc. If AT 2 determines notto transmit the at least one object in its first format, the processreturns to 925D and the application server 170 continues to send themultiple objects to AT 2 (without sending all of the objects to AT 1 intheir first realization). Otherwise, if AT 2 determines to transmit theat least one object in its first format to AT 2, the application server170 continues to send the multiple objects to AT 1 while sending theobjects modified in 920D to AT 2 in their original or unmodified, firstrealization, 935D.

In FIG. 9D, it is possible that the download request 900D corresponds toreal-time or streaming media. In this case, it will be appreciated thatif a low-resolution video, for example, is sent to a user, there islittle value in sending the higher-resolution video to the user when theuser re-connects to a higher-performing network or its connectionotherwise improves. In this case, blocks 930D and 935D can potentiallybe omitted for streaming or real-time sessions in an embodiment of theinvention, where ‘old’ files have less value than more recent files,even if the older files were sent with lower quality.

While FIGS. 9A through 9D are described as separate processes above, itwill be appreciated that two or more of FIGS. 9A through 9D can beimplemented in a coordinated manner in other embodiments of theinvention. For example, the prioritization-focused embodiments of FIG.9A, FIG. 9B and/or FIG. 9C can be implemented in conjunction with thelimited environment-focused embodiment of FIG. 9D. In this case, inaddition and/or in place of modifying the realizations of the multipleobjects in 922D, the transition of AT 2 to the limited environment maycause the object transfer priorities of FIG. 9A, FIG. 9B and/or FIG. 9Cto be modified. In another example, FIG. 9A, FIG. 9B and/or FIG. 9C maysimply be executed in parallel with FIG. 9D but may not actually bedirectly affected by FIG. 9D. For example, the multiple objects that aredescribed as transferred from AT 1 to AT 2 in FIG. 9D may be provided inan order based on the respective object transfer priorities of FIG. 9A,FIG. 9B and/or FIG. 9C.

Further, while each of FIGS. 9A through 9D are directed to embodimentswhereby objects are transferred from AT 1 to AT 2, it will beappreciated either of AT 1 and/or AT 2 may be representative of multipleATs. In other words, the objects arriving at AT 2 in FIGS. 9A through 9Dcan alternatively originate from multiple ATs instead of a single AT 1.Also, the objects sent from AT 1 in FIGS. 9A through 9D canalternatively be sent to multiple target ATs instead of a single AT 2.

In the case of AT 2 being one of a plurality of ATs that are receivingthe objects from AT 1, with respect to FIGS. 9A through 9C, it will beappreciated that each AT receiving the objects from AT 1 can beassociated with its own respective object transfer priority. Thus, theprocesses of FIGS. 9A through 9C can be executed for each respectivereceiving AT, potentially resulting in the objects from AT 2 beingdelivered to the respective receiving ATs in different orders. Withrespect to FIG. 9D, it will be appreciated that the entry of one of thereceiving ATs to a limited environment need not limit the objectstransferred to other receiving ATs that are not in a limitedenvironment. Thus, the execution of FIG. 9D may affect less than all ofthe receiving ATs.

Further, in any of FIGS. 9A through 9D, one or more of the objects beingtransferred may be associated with an expiration time whereby, after theexpiration time, a value associated with the one or more objects isdecreased and/or eliminated entirely. Accordingly, during objecttransfer, a given entity can check a current time against the associatedexpiration times for the one or more objects to determine whether todynamically de-prioritize the one or more objects and/or drop the one ormore objects entirely. In an example, this operation may occur at AT 1during 924A of FIG. 9A, 920B of FIG. 9B, 924C of FIG. 9C and/or 920D ofFIG. 9D. Alternatively, this operation may occur at the applicationserver 170 during 925A of FIG. 9A, 925B of FIG. 9B, 925C of FIG. 9Cand/or 925D of FIG. 9D.

Those of skill in the art will appreciate that information and signalsmay be represented using any of a variety of different technologies andtechniques. For example, data, instructions, commands, information,signals, bits, symbols, and chips that may be referenced throughout theabove description may be represented by voltages, currents,electromagnetic waves, magnetic fields or particles, optical fields orparticles, or any combination thereof.

Further, those of skill in the art will appreciate that the variousillustrative logical blocks, modules, circuits, and algorithm stepsdescribed in connection with the embodiments disclosed herein may beimplemented as electronic hardware, computer software, or combinationsof both. To clearly illustrate this interchangeability of hardware andsoftware, various illustrative components, blocks, modules, circuits,and steps have been described above generally in terms of theirfunctionality. Whether such functionality is implemented as hardware orsoftware depends upon the particular application and design constraintsimposed on the overall system. Skilled artisans may implement thedescribed functionality in varying ways for each particular application,but such implementation decisions should not be interpreted as causing adeparture from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits describedin connection with the embodiments disclosed herein may be implementedor performed with a general purpose processor, a digital signalprocessor (DSP), an application specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A general purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

The methods, sequences and/or algorithms described in connection withthe embodiments disclosed herein may be embodied directly in hardware,in a software module executed by a processor, or in a combination of thetwo. A software module may reside in RAM memory, flash memory, ROMmemory, EPROM memory, EEPROM memory, registers, hard disk, a removabledisk, a CD-ROM, or any other form of storage medium known in the art. Anexemplary storage medium is coupled to the processor such that theprocessor can read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anASIC. The ASIC may reside in a user terminal (e.g., access terminal). Inthe alternative, the processor and the storage medium may reside asdiscrete components in a user terminal.

In one or more exemplary embodiments, the functions described may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the functions may be stored on ortransmitted over as one or more instructions or code on acomputer-readable medium. Computer-readable media includes both computerstorage media and communication media including any medium thatfacilitates transfer of a computer program from one place to another. Astorage media may be any available media that can be accessed by acomputer. By way of example, and not limitation, such computer-readablemedia can comprise RAM, ROM, EEPROM, CD-ROM or other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother medium that can be used to carry or store desired program code inthe form of instructions or data structures and that can be accessed bya computer. Also, any connection is properly termed a computer-readablemedium. For example, if the software is transmitted from a website,server, or other remote source using a coaxial cable, fiber optic cable,twisted pair, digital subscriber line (DSL), or wireless technologiessuch as infrared, radio, and microwave, then the coaxial cable, fiberoptic cable, twisted pair, DSL, or wireless technologies such asinfrared, radio, and microwave are included in the definition of medium.Disk and disc, as used herein, includes compact disc (CD), laser disc,optical disc, digital versatile disc (DVD), floppy disk and blu-ray discwhere disks usually reproduce data magnetically, while discs reproducedata optically with lasers. Combinations of the above should also beincluded within the scope of computer-readable media.

While the foregoing disclosure shows illustrative embodiments of theinvention, it should be noted that various changes and modificationscould be made herein without departing from the scope of the inventionas defined by the appended claims. The functions, steps and/or actionsof the method claims in accordance with the embodiments of the inventiondescribed herein need not be performed in any particular order.Furthermore, although elements of the invention may be described orclaimed in the singular, the plural is contemplated unless limitation tothe singular is explicitly stated.

What is claimed is:
 1. A method of exchanging data between a firstaccess terminal and a second access terminal in a communications system,comprising: receiving, at the first access terminal from the secondaccess terminal, data in conjunction with a streaming communicationsession, wherein the data is received while a first set of windows of adisplay of the first access terminal is active and/or prominentlydisplayed on the display; detecting a transition of the display of thefirst access terminal from the first set of windows to a second set ofwindows; and transmitting, based upon the detected transition, a requestto de-prioritize a portion of the streaming communication sessionassociated with the first set of windows.
 2. The method of claim 1,wherein the first set of windows is associated with a video-portion ofthe streaming communication session, wherein the detected transitioncorresponds to a detection that the first access terminal is no longerdisplaying the video-portion of the streaming communication session, andwherein the transmitted request to de-prioritize corresponds to arequest to reduce a rate at which the video-portion of the streamingcommunication session is received or to stop receipt of thevideo-portion of the streaming communication session.
 3. The method ofclaim 2, further comprising: continuing to receive an audio-portion ofthe streaming communication session after the vide-portion of thestreaming communication session is reduced and/or stopped in response tothe request to de-prioritize.
 4. The method of claim 1, furthercomprising: detecting a transition of the display of the first accessterminal back to the first set of windows; and transmitting, based uponthe detected transition back to the first set of windows, a request tore-prioritize the portion of the streaming communication sessionassociated with the first set of windows.
 5. The method of claim 4,wherein the first set of windows is associated with a video-portion ofthe streaming communication session, wherein the detected transitionback to the first set of windows corresponds to a detection that thefirst access terminal has resumed an attempt to display thevideo-portion of the streaming communication session, and wherein thetransmitted request to re-prioritize corresponds to a request toincrease a rate at which the video-portion of the streamingcommunication session is received or to resume receipt of thevideo-portion of the streaming communication session.
 6. The method ofclaim 1, further comprising: receiving, at the first access terminalfrom the second access terminal after the transmission of the request tode-prioritize, data in conjunction with a file-transfer session that isseparate from the streaming communication session, wherein the requestto de-prioritize is transmitted to increase a rate at which the firstterminal receives the data in conjunction with the file-transfersession.
 7. A method of exchanging data between a first access terminaland a second access terminal in a communications system, comprising:transmitting data to the first access terminal from an applicationserver arbitrating a streaming communication session between the firstand second access terminals; receiving, from the first access terminal,a request to de-prioritize a portion of the streaming communicationsession; and modifying the data being transmitted to the first accessterminal in accordance with the de-prioritization request.
 8. The methodof claim 7, wherein the portion of the streaming communication sessioncorresponds to a video-portion, and wherein the modifying step continuesto transmit at least an audio-portion of the streaming communicationsession.
 9. The method of claim 7, wherein the modifying step reduces arate at which the portion of the data is transmitted to the first accessterminal.
 10. The method of claim 9, wherein the portion corresponds toa video-portion of the streaming communication session.
 11. The methodof claim 7, wherein the modifying step stops transmitting the portion ofthe data to the first access terminal.
 12. The method of claim 11,wherein the portion corresponds to a video portion of the streamingcommunication session.
 13. The method of claim 7, further comprising:receiving, from the first access terminal, a request to re-prioritizethe portion of the streaming communication session; and resumingtransmission of the portion of the streaming communication session inaccordance with a manner in which the portion was transmitted to thefirst access terminal prior to the modification.
 14. A method ofdownloading objects to an access terminal, comprising: determining todownload a plurality of objects to the access terminal; determining thatthe access terminal is operating in a limited environment relative tothe plurality of objects to be downloaded to the access terminal;configuring one or more requests for the plurality of objects with anindication that the access terminal is operating in the limitedenvironment; transmitting the one or more configured requests for theplurality of objects; and receiving, in response to the one or moretransmitted requests, an altered version of the plurality of objects,wherein the altered version of the plurality of objects are altered toconform with the limited environment of the access terminal.
 15. Themethod of claim 14, wherein the determination that the access terminalis operating in the limited environment relative to the plurality ofobjects to be downloaded to the access terminal is based on a connectionquality indicator received from an application server providing theplurality of objects to the access terminal, or wherein thedetermination that the access terminal is operating in the limitedenvironment relative to the plurality of objects to be downloaded to theaccess terminal corresponds to a first determination that a currentoperating environment of the access terminal is bandwidth-limited, orwherein the determination that the access terminal is operating in thelimited environment relative to the plurality of objects to bedownloaded to the access terminal corresponds to a second determinationthat a download of the plurality of objects is expected to take longerthan a threshold period of time in the current operating environment ofthe access terminal.
 16. The method of claim 14, wherein the pluralityof objects are associated with a website or a file-transfer sessionbetween the access terminal and another access terminal.
 17. The methodof claim 14, wherein the altered version of the plurality of objects isassociated with lower-quality as compared to an un-altered version ofthe plurality of objects.
 18. The method of claim 17, wherein thealtered version of the plurality of objects has a lower resolution ascompared to the un-altered version of the plurality of objects.
 19. Themethod of claim 14, further comprising: receiving, after the alteredversion of the plurality of objects are received, an un-altered versionof one or more of the plurality of objects.
 20. The method of claim 19,wherein the reception of the un-altered version of the plurality ofobjects is triggered by (i) the altered version of the plurality ofobjects completing reception at the access terminal, (ii) entry of theaccess terminal into a non-limited environment, (iii) and/or after athreshold period of time elapsed following the reception of the alteredversion of the plurality of objects at the access terminal.